On Sun, Jul 01, 2001 at 02:07:38PM -0400, Joey Hess wrote: > Joey Hess wrote: > > It'd be rather nice if we could get unstable and/or an apt repository > > set up to easily make debian fully LSB compliant, soonish. Realistic? > > Ignoring the library versioning stuff, the only obvious points of > incompatability that could not be easily dealt with by a lsb.deb are are: > > * LSB requires that user bin have uid and gid 1 (why?). On my box anyway, > daemon is uid 1, and bin is 2. you would think they would know history, this was done away with long ago because of NFS mounted /usr. > * LSB says that if a "operator" user exists, it should be in group root. > We have a group "operator" instead. what is operator even used for anyway? this looks like more `lets look at redhat and make whatever we see `standard'' > * LSB says that nobody's group should be called "nobody", while we have > "nogroup". Bah. OpenBSD has both a nobody and nogroup :shrug: if we want to bother caring about this one just add a nobody group in addition to the nogroup group. > * LSB requires bash as the shell, and allow use of at least some bashisms. > Well, that's default in debian, but it's trivial these days to install ash > and make it the default shell. Does this mean that debian violates the LSB? that sucks. #!/bin/sh should mean straight posix. allowing bashisms in #!/bin/sh does nothing more then break compatibility with other *nixes, even Free ones like *BSD. yes yes what a great `standard' we have here... > * LSB defines runlevels, while we define 2-5 identically by default. > 2 multiuser with no network services exported > 3 normal/full multiuser > 4 reserved for local use, default is normal/full multiuser > 5 multiuser with xdm or equivalent more `lets make whatever redhat does standard!' runlevels are sysadmin policy, not some retarded `standards' group. ignore this. > * LSB init scripts have these "facility names" in them, which specify when > the script may be run in the init sequence. Examples: > $local_fs all local filesystems are mounted > $network low level networking (ethernet card; may imply PCMCIA running) > $named named is operational > While this doesn't directly conflict with debian style numbered init > scripts, if we support the LSB we will need a way to tell when these > faclities are present so that whatever runs the lsb init scripts can do so. > Or we can just run all lsb init scripts last in the boot sequence. :-P your solution is best. > * They want LANA to assign names of init scripts, under the assumption, it > seems, that LSB init scripts should be able to have short and simple names, > while not conflicting with the names of any of the init scripts of any of > the distributions. > > This is IMHO very problimatic. While LANA will presumably assign all the > standard init script names like cron and gpm and so on to the obvious and > correct daemons (and indeed there is a long list of pre-assigned names like > that in the usb), it limits debian's flexability, and it means that if a > developer wants to make a package with some wild and strange and little known > daemon[1], they would have to apply to LANA first, or give the script the > disgusting named "debian.org-<foo>" or Debian would become LSB-non-compliant > again. Yuck. This is IMHO the worst intrustion into the distribution's > territory by the LSB. They should have just required LSB init scripts be > prefixed with lsb- ... gross. i vote for ignoring this one as well. > Overall, I don't know why this standard was assigned a version number of > 1.0, since it has a quite thrown-together feel to it. Maybe they just want > people to look at it, in which case the 1.0 served its purpose here. But 1.0 > also means there is going to be pressure to implement it. Hmm. pressure by who? corporations? who cares. -- Ethan Benson http://www.alaska.net/~erbenson/
Attachment:
pgptg3BXeKqs_.pgp
Description: PGP signature