Re: real LSB compliance
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.
* LSB says that if a "operator" user exists, it should be in group root.
We have a group "operator" instead.
* LSB says that nobody's group should be called "nobody", while we have
"nogroup". Bah.
* 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?
* 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
* 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
* 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- ...
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.
--
see shy jo
[1] For example, I am writing a daemon right now called "mood". Why? Because
it's a cute pun (and I won't explain it, doogie ;-). I don't intend to
ever apply to LANA, since it's a very obscure daemon.
Reply to: