Sune Vuorela <report...@pusling.com> reported
>Runit does cat/sed magic on /etc/inittab on installation and removal.
True.
> it looks like a clear violation of 10.4.7.
ITIYM 10.7.4
My analysis:
/etc/inittab is not a Debian 10.7.1 conffile, it is rather a
configuration file, owned and managed (cough) by sysvinit.
The sysvinit postinst does a
if [ ! -f /etc/inittab ]
then
cp -p /usr/share/sysvinit/inittab /etc/inittab
fi
which satisfies policy 10.7.3.
Now we get to 10.7.4, and see if the "two or more packages use
the same configuration file and it is reasonable for both to be
installed at the same time" section can apply to sysvinit and runit.
Well, runit does not depend on sysvinit, but that shouldn't be a
problem, since sysvinit is Essential: yes / Priority: required.
Also, when the system is fully runit-ized with runit-run, sysvinit
and inittab become irrelevant, so the "is capable of operating without
it" clause applies.
"If it is desirable for two or more related packages to share a
configuration file and for all of the related packages to be able
to modify that configuration file" -- I assert that is actually what's
going on here, although sysvinit never modifies inittab other than
providing an initial version -- "then (chop) 1. [the owner] will
manage the configuration file with maintainer scripts as described
in the previous section." Check.
"The owning package should also provide a program that the other
packages may use to modify the configuration file."
Sounds like a wishlist bug should be filed against sysvinit.
In the absence of that program, the cat/sed magic is properly
designed to do what such a program would do.
My vote:
1. File above-referenced sysvinit wishlist bug
2. Downgrade and/or tag this bug as lenny-ignore
3. Mark the sysvinit bug as a blocker for this bug
Note that the inittab file structure has not been updated since
SysV was introduced in 1983. Most other configuration-files-that-
are-a-list in Debian have been "upgraded" to a form that allows
easier and more reliable automated maintenance, e.g., /etc/ld.so.conf
becomes /etc/ld.so.conf.d/*.conf. But inittab is "special", being
so old, so standard (e.g., busybox also implements this file), and
needed at such an early stage in the boot process. For most programs,
the sysvinit script system is an adequate place to slide in. But since
one of the points of runit is to replace that ancient infrastructure with
something better, it is designed to worm itself down the boot process
chain -- when runit-run is installed, bypassing sysvinit completely.
I can't see "fixing" this bug by changing either runit or sysvinit this
close to the lenny release. The risk of breakage is too real. I also
don't see this bug as having any practical importance.
Let me close with a reference to my 2005 essay "Unix Daemon Foundations"
http://recycle.lbl.gov/~ldoolitt/foundations.html
Personally, I wish for better runit or other sysvinit-replacement
support post-lenny.
- Larry
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
