Re: ifupdown writes to /etc... a bug?

[Thomas Hood <jdthood0@yahoo.co.uk>]

(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 <jdthood0@yahoo.co.uk>