On Thu, Jul 05, 2001 at 04:56:02AM +1000, Anthony Towns wrote: > 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.'' this makes sooo much more sense. and doesn't require debian to adopt deficient practices. (telling the admin how he should configure runlevels) > > 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)." those books wouldn't match debian anyway, even if we did take that silly runlevel nonsense. unlike redhat xdm is trivially removable, it won't necessarily ever get installed in the first place. > > 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...) i don't see why a distributer would ever want to ship files owned by bin anyway... the best solution to this deficient format is changing the ownership in the postinst if thats really necessary. (which in 99% of cases its not). most cases where you want non root:root ownership is special purpose setuid binaries (man) or special purpose daemons like MTAs. in both of those cases you won't necessarily have a static uid anyway, thus you must use a script to create and use dynamically allocated uids. > 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. and it only matters if the program really has a need to use special ownership, most won't, or those that do will need to create dynamically allocated accounts anyhow. btw what does the LSB have to say about that? are lsb packages allowed to destroy the passwd file if they feel like it? or must they use a wrapper like adduser? (which is not a symlink to useradd). -- Ethan Benson http://www.alaska.net/~erbenson/
Attachment:
pgp9xqB_LuJBX.pgp
Description: PGP signature