[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



On Tue, Mar 11, 2003 at 02:26:27PM +0100, Emile van Bergen wrote:
> On Tue, Mar 11, 2003 at 12:20:27PM +0000, Colin Watson wrote:

> > On Tue, Mar 11, 2003 at 12:49:32PM +0100, Emile van Bergen wrote:
> > > On Tue, Mar 11, 2003 at 10:21:33PM +1100, Glenn McGrath wrote:
> > > > /run is more obvious than /mem to me as its intended use is similar to
> > > > /var/run which is clearly defined.

> > > That's true, but /mem can be just as clearly defined, as shown earlier.

> > I'd prefer to name things based on their intended purpose than on their
> > intended implementation. The former allows you more flexibility when you
> > come up with a better implementation later, or when it turns out that
> > your intended implementation isn't possible due to local constraints.

> True, that's the general rule.

> However, as /mem refers more to properties more than implementation, I
> don't think it's much of a problem, especially because the most
> prominent properties that /mem refers to by association, are
> hard requirements to fulfill the intended purpose.

> Another rule in my book is that if you can either solve a problem with
> something very specific or just as elegantly with something generic, you
> shouldn't limit the creativity of the people that come after you, and
> choose the more general solution.

> /mem can both be used for the things we're finding a solution for, the
> /early-writable-and-always-cleared-but-more-general-variant-of-var-run,
> and for things that we cannot forsee yet.

> If you always want to name things after their purpose instead of
> their properties, you make it more awkward to use those things to be
> used for other purposes, even if they turn out to be a perfect fit.

Except that it's *NOT* a perfect fit; you're already trying to overload
the meaning of this proposed directory by adding a subdirectory used for
state that's persistent across reboots.  Having subdirectories with
different semantics than the parent directories is part of what got us
into the current mess.

The FHS already has a place for persistent state -- /var/lib.  I don't
see any reason why ntp can't use /var/lib/ntp/ (which it currently does);
AFAIK, all of the init scripts that need persistent storage are run after
NFS shares are mounted.  If you want to use shared memory for this so you
don't spin up your disks, that's fine -- on *your* systems -- but it has
nothing to do with the issue at hand, namely, that the FHS does not give
us a usable location for the non-persistent, non-config files currently
being stored under /etc.

-- 
Steve Langasek
postmodern programmer

Attachment: pgp5ZGtFHSmmN.pgp
Description: PGP signature


Reply to: