Date: Thu, 15 Feb 1996 19:32:32 -0800 From: Lyndon Nerenberg VE7TCP <lyndon@orthanc.com> To: freebsd-current@freebsd.org Subject: Hysterical Raisons Message-ID: <199602160332.TAA00541@multivac.orthanc.com>
next in thread | raw e-mail | index | archive | help
The comments about /usr/local/man vs /usr/local/share/man and the libexec vs sbin directories are reasonable. All that's missing is a firm policy statement on where things belong. It seems to me that a modification to the hier(7) man page would suffice. For most non-distribution binaries a simple s;/usr;/usr/local; would work. (tmp being an exception, and there will be a couple of others.) What's important is to make sure the policy is enforced. Of course this opens up the /usr/ports can of worms again. The /usr/local turds in question seem to all come from source code in /usr/ports. If we're going to mandate a hierarchy convention for /usr/local it's going to be pretty tough to exempt /usr/ports from that, isn't it? /usr Core team software distribution /usr/ports Unsupported ported code /usr/local Whatever the *LOCAL* site wants to add Each with an appropriately adjusted hier(7) layout underneath it makes for a nicely consistent filesystem layout. We (CSRG actually) have already proven this works for the /usr tree. I don't think anyone can argue that it won't work for the others. The only reason the ports collection overlaps /usr/ports and /usr/local is simple intertia. Someone has to do the work. I'm willing to volunteer my time to help clean up the ports tree to make it self-consistent underneath /usr/ports. Who else is? I'm willing to help with the cleanup provided that any *future* imports to the ports tree have the FS layout convention enforced. It would also be nice if there was some form of review in place to ensure that the man pages for things in the ports collection were changed to reflect the changes to the binaries. Too many of them reference absurd file locations. --lyndon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602160332.TAA00541>