Re: real LSB compliance
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.
> * 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.
All ugh. If we care enough, we could change these, I expect... but
it'd be a pain, and IMHO not worthwhile.
> * 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?
If the LSB is going to go to the extent of specifying a new name for
the DYNAMIC LINKER to enforce LSB compatibility, it had damn well
better specify a name (preferably bash, rather than some new one) for
the shell. Requiring /bin/sh = bash is hopelessly short-sighted. If
they really do mandate that, I'm going to encourage Debian in some
deliberate non-compliance.
> * 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 would be a good thing for us to pick up, I think.
> * 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
I'm with that :) LSB things can't depend otherwise on the order of the
system's initialization, can they? Unless you expect to have some
system services depend on them; for instance a VPN package. But I
doubt the standard covers the framework for that anyway.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
Reply to: