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 <email@example.com>
> 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 <firstname.lastname@example.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
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 <email@example.com>