Re: real LSB compliance
Daniel Jacobowitz 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?
>
> 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.
I may have misread the LSB. They do say that bash is the standard shell.
Then, contradicting that, they say that they want to work with bash's
authors to get it to full POSIX compliance, and:
It should be noted that Bash supports many extensions -- features of a
supplemental nature -- to those explicitly specified in POSIX-1003.2.
Such extensions to POSIX are not beneficial to the portability of a
shell script. The use of extensions must be avoided in order for a
shell implementation or shell script to be considered LSB-compliant.
And then it further goes on to list two deviations from POSIX in the
shell. Very odd and trivial deviations to pick IMHO. They are:
* ". foo" when sourcing an executable, but non-readable file, should
give an error message. Seems posix "ignores" them (I have not
checked posix). Big deal.
* set argv[0] to the _full_ pathname of the program the shell has run,
if the program was found by searching PATH. Seems posix just sets it
to the basename. Ho hum, big deal (ash does this anyway).
> > * 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.
Arguably. It has its advantages and I'm sure would piss of some people.
> > * 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.
The lsb does not offer or mandate a way for the system's init sequence
to depend on a LSB package. That would be pretty evil too, since the LSB
is all about evil prioprietary binary-only crap, right? :-)
--
see shy jo
Reply to: