On 06 Nov 2006 09:57 PM or thereabouts, Roy Marples wrote: > On Monday 06 November 2006 22:06, Alec Warner wrote: > > Roy Marples wrote: > > > On Monday 06 November 2006 18:27, Matthew Snelham wrote: > > >> From a filesystem usage point of view though, storing actively changing > > >> state data on /lib is ugly. The tmpfs /lib/rcscripts/init.d overlay > > >> solution for a ro / works, but as long as tmpfs magic is needed, can't > > >> it be written to /var after localmount? > > > > > > It could be written to /var at the end of an rc. > > > However, you then have to guarantee that /var is always available too and > > > that may not always be the case as some people want to have /var net > > > mounted or something equally silly :) > > > > > > /lib may be ugly, but it's also guaranteed which is what I'm more > > > interested in. > > > > This screams "vustomizable" > > > > Just give us a variable we can set to move it; obviously there is no > > "One True Location" for everyone. > If you want that level of flexability then simply symlink /lib/rcscripts > to /var/rcscripts or where-ever you like.
But then baselayout is still 'behaving badly' by sttempting to store dynamic state information in /lib. Something it has not done before, to the best of my knowledge (with the exception of /dev state tarballs, which are generally acceptable, since they don't change while the system is up). UNIX filesystem usage patterns are older than a good chunk of gentoo devs, so in the name of defaulting to expected behaviour, I think /lib should be avoided. > From my perspective, state data always has to be available and writeable, > regardless of how simple or fancy the user has configured their layout. > So this means I have access to /bin, /dev, /etc, /lib, /sbin as those > directories have to exist on /. /usr and /var have to be accessable for a working system... and if init fails before those are availible, the system is non-functional regardless. So a tmp storage location is needed for state data early in the boot process (before writeable filesystems can be assured), and can flip before the boot runlevel is completed. (I've built a number of clusters with NFS root fs, but I've never even heard of a disk backed root with an NFS /var. Can we say that's pathologically odd, and unsupported/unsupportable?) > Why do we have to have everything configured by variables? Eh, I'm not sure I see the need for this to be a variable. I'd just like to see it well behaved. --Matthew [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
