On Wed, Jul 04, 2001 at 09:31:47AM -0400, Theodore Tso wrote:
> The one place where runlevels are specified are in the structured
> comments at the beginning in init scripts.
*blink*
Wasn't the point of those structured comments to get rid of all the
hardcoded numbers? I was expecting that lsb/install_initd would deduce
the runlevel/s based on the Required-Start: stuff; eg a header:
# Required-Start: $network, $multiuser
would put the service in runlevels 3,5 on Red Hat, and 2,3,4,5 on Debian;
whereas:
# Required-Start: $multiuser
would put it in runlevel 2,3,4,5 on both Red Hat and Debian.
Changing the wording to something like:
``For the purposes of the Default-Start: and Default-Stop: comment
headers, the valid runlevels are:
1 -- single user
2 -- multiuser, no networking
3 -- multiuser, networking
4 -- X, multiuser, no networking
5 -- X, multiuser, networking
The actual runlevels used by the distributor or the local user
may not match these values, but the distributor is required to
translate them to the appropriate local runlevels.''
Hrm. As an implementation issue, it'd probably be a good idea for the
"lsb-remove" script to run `remove_initd' itself, on the offchance the
LSB package doesn't clean up after itself properly. It should be possible
to make a fairly clean uninstall of an LSB package, even if it's fairly
lazy and buggy about doing so itself. (Without needing any changes to the
spec even, just as a point of interest)
> So as Alan mentioned, yes, you could map those runlevels to different
> values if you really wanted, and then have the install_initd script do
> the right thing when making the rc?.d links.
The spec should probably document this where it talks about runlevels,
then.
> Then the main way you might lose would be documentation and/or books
> that make assumptions about runlevels. (i.e, a Beginning Linux book
> which talks about using "telinit 5" to enable XDM --- since that works
> on basically all other mainline distributions except Debian. But that
> strictly speaking isn't an LSB issue.)
"This service is only run when you are in a runlevel that supports networking
(see your distribution manual to work out which runlevels these are)."
On Wed, Jul 04, 2001 at 11:12:36AM -0400, Theodore Tso wrote:
> > As has been pointed out elsewhere, Debian has uid/gid 2 for user/group
> > bin, and has daemon as uid 1. It's not at all clear why this needs to
> > be standardised -- uid 1 has no special meaning as far as I'm aware;
> > and user/group bin is easily specified by name.
> CPIO format files specify file ownerships by numeric ID, not by name.
I don't have anything useful to say here, I just wanted to gag publically.
(I don't see why you'd care about distributing LSB stuff in CPIO format,
personally. You just went to all that trouble to let them distribute it in
rpm format, after all...)
> So for
> distributions that want to use cpio as a transport medium, userids do
> become an issue.
It's only ISV's that use cpio as a transport medium where it
matters. Distributors who want to translate the rpm to cpio before
they install it, will just need to be careful about mapping the names
to numbers.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``_Any_ increase in interface difficulty, in exchange for a benefit you
do not understand, cannot perceive, or don't care about, is too much.''
-- John S. Novak, III (The Humblest Man on the Net)
Attachment:
pgpQVvaErXxea.pgp
Description: PGP signature