Re: real LSB compliance
On Sun, Jul 01, 2001 at 02:07:38PM -0400, Joey Hess wrote:
> * 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?
Umm... where does it say that it's OK to use bashisms? In the init
functions section it states that the *distribution* *provided*
*aliases* may take advantage of bash extensions, the init.d functions
provided by LSB-compliant applications should only depend on POSIX.2
/bin/sh features.
When this topic was discussed, we explicitly tried to make sure that
we didn't make the assumption that /bin/sh was bash. (Although if
some distribution wants to make that requirement, then
distribution-provided shell scripts may use bashisms, of course.) If
you think you've found a place in the spec where it requires
LSB-compliant distributions to use bash as /bin/sh, please let us know.
> * 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
This was discussed a long time ago, and there were some Debian
developers participating at the time when this decision was made.
Arguably this is stuff which FHS should have standardized a long time
ago, but unfortunately it didn't, which has caused no end of
inter-distribution compatibility headaches as a result.
> * 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
These facility names are placed in the structured comments in the
init.d shell script. The idea is that the distribution-provided
init.d installation program can read these facility names and
determine what /etc/rc.d S/K numbers should be used when installing
the init.d program.
You *could* run all of the lsb init scripts last, but then if there's
some special installable filesystem (say, the veritas filesystem)
which is provided as an LSB package, then if Debian always runs LSB
scripts last, then Debian systems wouldn't be able to use that
filesystem very effectively.
> * 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.
Actually, technically we don't *require* that distributions assign the
name of init scripts. We require that LSB compliant application
assign the name of init scripts. It's a good idea if distributions
were to register their init scripts, since doing so effectively acts
as a reservation to prevent ISV's from grabbing an init.d name. We've
tried to pre-reserve a number of init script names which are in common
use by many distributions, but that list is certainly not perfect.
If someone provides me a list of all init.d names used by Debian, I
will take care of making sure they are reserved so that LSB packages
won't try to grab them.
> [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.
You don't *have* to reserve it to the LANANA. But if you don't and
some LSB package grabs the name for something else completely
unrelated (say, SGI packages their patented technology for generating
cryptographic random numbers by pointing an IndyCam at a lava lamp),
and they happen to use the init.d script name "mood" to run their
moodd daemon for harvesting cryptographic randomness, the resulting
filename conflict will cause dpkg to refuse to install their LSB
package and your package simultaneously. And if they register the
name first, they will have the moral high ground in claiming the
script name, and Debian users who might want to install both SGI's
program and your program will file a bug against your package.
Finally, we tried very hard to make the standard a good one. We had a
month-long comment period, and we tried hard to get people to look at
it and send us comments. Unfortunately, many folks didn't choose to
participate or to read and send us comments until after LSB 1.0 was
finalized. That's not the end of the world; we can make bugfixes in
LSB 1.1; but some changes would have been much, much easier to make if
people had participated from the very beginning.
- Ted
Reply to: