Removal of /stand Directory

From: Ryan Sommers (ryans_at_gamersimpact.com)
Date: 10/17/04

  • Next message: Garrett Wollman: "Re: Proposal to restore traditional BSD behavior in <strings.h>."
    Date: Sat, 16 Oct 2004 23:37:22 -0500
    To: arch@freebsd.org
    
    

    After a thread on current@ and private discussion following, myself and
    the other party were in agreement that /stand serves no purpose after
    the initial install. Most of /stand is duplicated in /rescue with the
    exception of a few members. This makes the approx. 3mb of space consumed
    by /stand wasted space.

    The only post-install dependency on /stand I can find is the diskless rc
    script. This script uses /stand/cpio and /stand/gzip for unpacking
    template archives to populate memory disks. I have come up with two
    solutions that would solve this problem. The first involves /bin/pax and
    moving gzip to /bin/gzip. This would be enough to unpack archives for
    diskless systems. The other is to use /rescue/tar and /rescue/gzip.

    Currently /rescue uses gtar, however, this will likely be switched to
    bsdtar after 5.3-RELEASE (see PR bin/72549). This will add cpio and pax
    support to /rescue/tar (in addition to saving approx. 40k). I don't
    believe using /rescue is the correct solution for diskless systems.

    Which is why I propose moving gzip to /bin. This would increase /bin by
    about 46k. However, upon removing /stand the net would be a savings in
    the root partition. /bin/pax and gzip are capable of handling the
    diskless template archives and will also be updated as part of world to
    receive any bugfixes.

    If people agree with this, after providing patches for moving gzip to
    /bin I plan on addressing sysinstall to have /stand removed as part of
    the post-install cleanup/configuration. And then after I'd like to work
    on bringing our support and instructions for diskless environments up to
    date with 5.X.

    Anyone have any thoughts, objections, feelings on this? If anyone has
    already started work on this but doesn't have the time let me know and
    I'd be happy to pick up where they left off. Otherwise I'm willing to
    put in the grunt work if anyone is willing to help commit it once
    5.3-release is out of the way.

    -- 
    Ryan Sommers
    ryans@gamersimpact.com
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
    

  • Next message: Garrett Wollman: "Re: Proposal to restore traditional BSD behavior in <strings.h>."