Re: ifupdown writes to /etc... a bug?
(Replies to some comments made in the
RFC: New required package: libblkid1
thread, which really belong to the discussion that took
place under the subject heading
ifupdown writes to /etc... a bug? ...)
Theodore Ts'o wrote:
> /var is definitely local. To quote from the FHS:
> Some portions of /var are not shareable between different systems.
> For instance, /var/log, /var/lock, and /var/run.
This was asserted earlier. The reply was that unshareability
and locality are different properties. E.g., /var/log but can't
be shared between two systems for obvious reasons, but it needn't
be local (i.e., accessible independently of networking) either.
I suggest you read the "ifupdown writes to /etc... a bug?" thread.
> Let's optimize for the common case, not for the uncommon case.
This is a false dichotomy. The introduction of /run would be
no less optimal for the common case than for the uncommon case.
I understand the feeling that Debian should not add directories
to the root file system without good reason. However, reasons
have been presented on behalf of /run and some people think they
are good. Others disagree.
> Adjtime is explicitly called out by the FHS has living in /etc.
> I agree that it doesn't have to be, and that perhaps /var/state
> (*not* /var/run; the file definitely needs to be preserved
> across reboots) is a better place for it.
I don't see mention of /var/state in the current FHS.
Giacomo A. Catenazzi wrote:
> IMHO the better method is a short living /var.tmp
> After we mount /var, we move /var.tmp into /var
So ifupdown writes to /var.tmp/run/ifstate early on,
but later in the boot sequence must switch to using
/var/run/ifstate? That doesn't sound very reliable.
Matt Ryan wrote:
> We are in danger of going to far in wanting to satisfy
> any desire people have. While the argument has been made
> that some people view a r/o root filesystem as a
> requirement there are many others (the majority?) who
> don't and why should we all learn a new location
> for files when we don't need (or want) to? [...]
> lets aim for problems that
> effect the majority and not the few who want a r/o fs or
> run diskless clients.
I guess the argument here is that the desire for a read-only
root filesystem is frivolous. Someone trying to run Debian
from a ROM wouldn't feel that way, but he's just a MINORITY.
And we mustn't allow a MINORITY to inconvenience THE MAJORITY
so much as to learn a new location for a file!
Is that the argument? Hrm.
Thomas Hood <email@example.com>