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

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



On Wed, 2003-04-02 at 20:58, Andreas Metzler wrote:
> Wasn't the whole point of /run to move the _non_ configuration files
> out of /etc which only resided there because /etc was the only
> available writable place?

No, the point was to isolate run-time state files so that
they can be put somewhere writable and network-independent
(so, not in /var), persistent until reboot (so, not in /tmp),
yet not in / or /etc which some people would like to be on
read-only filesystems.  /etc/run can be a rw filesystem
even if / and /etc are ro.

Bernhard R. Link <blink@smtp.informatik.uni-freiburg.de>
> There is no reason to do half things. If there is a good
> solution why not implement the good one? Instead of
> something half?

I don't see /etc/run as something half.  So far as I can
see it completely meets the need.  It has the advantage
over /run that it won't require FHS politicking.  Whether
it is a more or less nice place to put the new directory
than /run is a matter of taste.

Joey Hess <joeyh@debian.org> wrote:
> Anyway, while it's not ideal, I'd rather see the state
> cruft in /etc moved to an /etc/run than see no change be
> made at all, which seems like the most likely outcome at
> this point. At least if it's in /etc/run, we'll have a
> good handle on what it is and it'll all be in one place
> to be moved elsewhere later.

The first thing required is agreement on the location.
Suppose it's /etc/run.  The next step is to move run-time
state files there.  Once things like ifstate and mtab have
been moved (by patching the programs that use these files,
and perhaps also by leaving behind symlinks), support for
/etc/run being on a separate filesystem can be added. 
Simultaneously, the required characteristics of /etc/run
must be documented, presumably in section 10.1 of the
policy manual.

In order to get the run-time state files moved to the
agreed-upon location, I suggest that wishlist bug reports
be filed against the affected packages, which will include
links to this thread and patch offerings.

Or should this whole issue be carried over to -policy
for further discussion first?

-- 
Thomas Hood <jdthood0@yahoo.co.uk>



Reply to: