Re: real LSB compliance
On Tue, 3 Jul 2001 tytso@mit.edu wrote:
> On Tue, Jul 03, 2001 at 06:10:50AM -0500, Scott M. Dier wrote:
> >
> > > * LSB defines runlevels, while we define 2-5 identically by default.
> > Isn't this a specific redhat-ism? I'm not impressed with using init to
> > handle xdm/gdm.
> Actually, most other Distributions are also using this runlevel
> scheme. Debian was the the only distribution which wasn't.
NB: this includes Slackware. The exact meanings of the runlevels vary from
distro to distro, but unlike on the question of RPM as a package format,
Debian has no allies wrt the runlevel issue. In fact, having come to Debian
through a Slackware -> RedHat -> Debian progression, I also find the lack of
distinguished runlevels somewhat annoying: when debugging problems with
specific startup scripts, I've always found switching runlevels to be an easy,
effective way to get the system to a certain desirable state. I don't think
asking distros to provide certain features in each runlevel by default (always
with the possibility of administrative override) is out of line in the LSB.
> Creating a new directory for the LSB packages would mean segregating
> them off into a "ghetto", so that users would have to type something
> else (say, /etc/lsb-init.d/oracle), where most other things would have
> been /etc/init.d. The same reasoning is why we didn't simply require
> all lsb-compliant packages to use an "lsb-" prefix. It didn't seem
> fair to force LSB packages to use a new and awkward namespace,
> especially when that namespace was going to be user-visible.
I have to disagree with this. For a variety of reasons, including those I've
enumerated previously on this list, LSB packages can never be as
well-integrated into the system as native packages; it is very likely that the
users who are going to be running init.d scripts are also going to notice
these scratches in the paint job. Rather than being awkward, I expect
administrators would find it quite comfortable to have third-party software
confined to a specific namespace in this manner.
I consider it sufficiently important for the distribution to maintain control
of this namespace that I would recommend that any Debian LSB compatibility
layer mangle the names of LSB init scripts.
> Where were all of the Debian developers when we started the one month
> review process before the final standardization of 1.0? We received a
> lot of comments and carefully considered all of them before putting
> out the 1.0 standard. Although it would have been much more
> convenient to have received these sorts of comments a year ago, it
> still would have been much easier for all concerned if we had received
> these comments a month ago, instead of now, after LSB 1.0 written
> specification has been released.
> Unfortunately, human nature being what it is, most folks refuse to
> actually pay attention to a standard until after it's finally released
> --- at which point they start kvetching. Well, if you don't like what
> happened with LSB 1.0, please help us with LSB 1.1! Volunteers are
> always appreciated.
It's also a function of human nature that the announcement of the standard's
completion was heard much more loudly than the announcement of the one month
review process. Sigh. I heard about the LSB on three mailing lists within 24
hours of its release, but apparently the review process wasn't noteworthy
enough to be mentioned on any of the mailing lists or news services I
currently follow. :/ (either that, or it just takes a flamewar before I
notice -- also not out of the question.)
Steve Langasek
postmodern programmer
Reply to: