On Mon, Dec 19, 2005 at 05:48:45PM +0100, Thomas Hood wrote: > > Note the definition for /usr/lib is "Libraries for programming and > > packages" and "/usr/lib includes object files, libraries, and internal > > binaries that are not intended to be executed directly by users or > > shell scripts." and /var/lib is "Variable state information" and "This > > hierarchy holds state information pertaining to an application or the > > system. State information is data that programs modify while they run, > > and that pertains to one specific host." > > > > Combining these two, and adding the "...needed to boot the system" > > qualifier seems like it would perfectly cover the above requirements > > and /run. > Let me see if I have understood the argument. Let's call the new > directory 'R' for now. > > <attempt to paraphrase> > /lib is, like R, a directory required for programs needed > to boot the system and run commands in the root filesystem; > and /var/lib is, like R, a place where data is stored. > We just heard "lib" twice! So /lib is the right place for R. > </attempt to paraphrase> "We just heard "lib" twice!" ? You either get to fairly summarise an argument or mock it; don't try to do both at once. The line of thinking is this: we would like to put everything in a single namespace under /, but we can't for two reasons: one is that / has to be small in some circumstances, so we use a separate namespace, /usr, that doesn't have that limitation; the other is that it's better to have separate read-only and read-write namespaces; so we put non-static information in /tmp, and /var. But beyond that, /, /usr, and /var are more or less the same -- hence /bin and /usr/bin, /lib and /usr/lib, and /tmp and /var/tmp, in each case, both directories containing the same sort of contents -- with the provisos that changing data goes in /var/foo, large static data goes in /usr/foo, and we limit /foo to stuff that's needed to boot or recover the system. If the question is "what does /lib contain?" the answer, then, is "the same sort of stuff that /usr/lib or /var/lib contains, but limited to that necessary to boot the system". > I don't think that an argument from the meaning of "lib" can get > much traction because /lib, /usr/lib and /var/lib are so different. They don't seem very different to me. /lib and /usr/lib both contain static libraries. /usr/lib and /var/lib both contain subdirectories of package specific data, split by the requirements of /usr and /var. /lib, /usr/lib and /var/lib are all a good default place for random data that people hadn't previously thought of. > (I'll guess that these differences are there because: > * /usr/lib contained both application code and application data > in the old days; So did /etc. Unlike /etc, /usr/lib remains *designed* to contain application code and data, currently. /lib in practice does the same thing today: containing .so files, kernel modules, script fragments, and terminal information. > * When application data was removed from /usr/lib it was placed > in /var/lib, which missed the opportunity to choose a more > appropriate name such as '/var/data'; For a brief time, /var/lib was renamed to /var/state, as it happens; it was renamed back when that proved unnecessarily cumbersome. > * When /usr/share was split out of /usr/lib, no /share was split > out of /lib. That would be because it's no easier to share /share across different machines than /usr/share, and because creating new directories in / is a bad idea. > But there are problems with this particular argument as I have > paraphrased it (probably distorting it). First, if we accept the > reasoning steps then the conclusion ought to be that the right value > for R is "/lib/lib". What went wrong? You pulled a "lib" from nowhere -- following the theory the "right" value for R in that case would be "<package>" or "misc". But that doesn't help distinguish an early read-write namespace, and seems kinda pointlessly pedantic. Afterall, if you're going to be that pedantic, /lib already forbids non shared libraries and non modules, so clearly /lib/run is unpossible. > So if we add _another_ directory with the same supporting role as > them then it should be, like them, in the root directory. Only if you also want to say "supporting directories of apps in /usr/bin should be, like them, in /usr, thus /usr/var/...". And while you might well say that, we don't. > Second, we missed the fact that the > function of R is more analogous to /var/run than to /var/lib, Actually we (I) deliberately ignored it; mostly because /var/run is a subset of the functionality of /var/lib, and "needed for boot" doesn't warrant breaking up the functionality like that. /lib/var would be the obvious alternative, and more accurately indicate "variable data needed early in bootup". *shrug* > and so > should have a basename of 'run' rather than 'lib'. Hence R should > be /run. Heh. I'm shocked -- shocked!! -- by your conclusion. > Briefly, if R is like /var/run except that it supports programs In theory, R is exactly like /var/run, and should in fact be /var/run. I'm not sure there actually are any situations where /var can't be mounted as soon as it's necessary; that may mean doing an NFS mount before running ifup; but that happens already if you've got an NFS mounted root fs, eg. In any event, the /var/run -> /run argument is fine, except that you *also* have to have a good argument why you can't just use an existing directory in /. > Here's another possible argument: > Putting R in /lib spoils the otherwise read-only > character of that directory. Putting R in / spoils the otherwise read-only character of that directory. *shrug* On Mon, Dec 19, 2005 at 06:01:15PM +0100, Thomas Hood wrote: > Anthony Towns wrote: > > Developers have been known not to be completely familiar with policy, > > but it's admins and upstream programmers that I'm particularly > > thinking of. > I don't see any problems arising from rampant /run use by _admins_. > They are always free to do what they want with their systems. Only in the sense that they're free to type "sudo mv /bin /Binaries" and live with the fact they can't login. If /run is a tmpfs, putting information that should be in /var will cause performance problems. Accidently encouraging that by our choice of naming isn't good behaviour on our part. > As for upstream programmers, most of them can't use /run because > their software doesn't run with root privileges. That is, pretty much everything that runs as a daemon, and that might have otherwise used /var in general. > I don't think that Debian would ever be accused of lacking zeal in > enforcing its Policy. :) Please see the other thread on RC bugs not getting fixed... Cheers, aj
Attachment:
signature.asc
Description: Digital signature