ctm(1) deprecation in the FreeBSD base system?
imp at bsdimp.com
Tue Oct 23 20:21:59 UTC 2018
On Tue, Oct 23, 2018 at 2:13 PM Rodney W. Grimes <
freebsd-rwg at pdx.rh.cn85.dnsmgr.net> wrote:
> > A cost(=time)/benefit look on moving ctm from src/ to ports/ :
> > - No tangible architecture benefit (its not like purging an old driver
> > to makes kernel support simpler, or avoiding clashing libs etc)
> > - FreeBSD would shrink 0.028 % of the size of src/
> > cd /pub/FreeBSD/branches/-current/src
> > du -s -k . # 1223922
> > du -s -k `find . -type d -name \*ctm\*`
> > 196 ./usr.sbin/ctm
> > 74 ./usr.sbin/ctm/ctm
> > 12 ./usr.sbin/ctm/ctm_dequeue
> > 44 ./usr.sbin/ctm/ctm_rmail
> > 18 ./usr.sbin/ctm/ctm_smail
> > dc 196 74 12 44 18 + + + + p 344
> > dc 344000000000 1223922 / p 281063 # then move 9 points
> > xcalc 344 / 1223922 # 0.0002810636
> > Those who would do the work might want to ponder if 0.028 % is best use
> > their time, or if more fun & benefit to work on some other part of
> FreeBSD ?
> At the most/least we should not go very far,
> the only thing that needs done soon is a gonein(13) commited
> to head and MFC'ed to stable/12 by thursday.
> All the other details should wait until a depreication policy
> revision is completed that includes how to deal with this.
There's no reason at all to wait. We can create the port. We can create the
github repo. We can move the history there. We won't be removing it before
we have a chance to socialize the removal and give people a chance to cut
over. None of this requires a new policy. Everybody agrees we should do it.
We shouldn't let some perceived policy get in the way of just moving
More information about the ctm-users