Re: ifupdown writes to /etc... a bug?
Goswin Brederlow wrote:
> Well, too late and not too late at all. The patch is send.
I am glad that you have set out to implement this idea.
However, I am not convinced that you are implementing it
exactly the right way. The /etc/volatile.conf file looks
like overdesign to me. I don't see the need for the path
to /whatever to be configurable by the user. Shouldn't we
just decide on a path (e.g., /etc/run) and then move the
run-time state files there by patching programs? Symlinks
can be used to ease the transition.
Anyway, I've taken a look at your patch. Here are some
> sysvinit (2.84-3.3) unstable; urgency=low
> sysvinit (2.84-3.2) unstable; urgency=low
> sysvinit (2.84-3.1) unstable; urgency=low
Put change descriptions in one entry in the changelog,
> volatile_mnt="`cat /etc/volatile.conf`"
Doesn't allow for comments in /etc/volatile.conf.
> if [ "$mnt" = "$volatile_mnt" ]; then
> # we have /run/
Comment is unneeded and is possibly wrong
> case "$fs" in
> # $volatile_mnt is on a real fs so fsck it
Case blocks are usually terminated with ';;'. I'm not sure
what you mean by a "real" fs. Could you be more explicit
> # Check the $volatile_mnt file system.
Instead of copying large blocks of code, I suggest you
write a function or two.
> # is on a ro fs until the remount succeeded. If $volatile_mnt
> # was found in /etc/fstab mount it and copy skeleton files.
I have read the whole thread and I don't recall reading
anything that explained why a skeleton directory is
needed. Presumably it is a kluge for backward compatibility.
If so, then this should be mentioned.
Also mention that you empty $volatile_mnt before filling
it with the contents of /etc/volatile-skel/.
> Things to do to use a read-only / filesystem:
The new README file needs some minor editing for English
You introduce the bug report with:
> after the big flamewar about writing to /etc on debian-devel ...
I don't think that this discussion has been a flamewar.
I haven't seen many personal attacks. It's been a good
discussion of many different possible solutions to a problem
Thomas Hood <firstname.lastname@example.org>