Re: LSB Spec 1.0 Criticism
On Wed, Jul 04, 2001 at 03:35:17PM +1000, Anthony Towns wrote:
>
> First, it'd be nice if there were a text version of the spec. HTML split
> into multiple pages, RTF and PDF are all pretty awkward. The HTML stuff
> could really use a "Next section" link, at least.
>
Agreed. If anyone knows how to configure the !@#!@# SGML software to
emit a single HTML file, that would both be useful for folks who want
to be able to quicky thumb through the entire standard in a web
broswer, as well as making it easy to generate a TXT version of the
spec by simply using lynx.
> What exactly is the purpose of the LSB spec these days? When I last
> worried about it, I was under the impression it was so that ISV's could
> distribute software packages in such a way that they would work and
> integrate well on a variety of distributions, and nothing more. That is,
> it wasn't about providing consistent functionality across distributions
> in general, or about standardising things for standardisation's sake.
> The "Purpose" section in the LSB spec doesn't seem to clarify this for
> me, but rather describes what the LSB is composed of, rather than why
> it's composed that way.
The primary purpose for the LSB is to provide binary compatibility of
executables across distributions.
In general while it is good to encourage distributions to not be
gratuitously different, that's at best a secondary goal of the LSB.
> As has been pointed out elsewhere, Debian has uid/gid 2 for user/group
> bin, and has daemon as uid 1. It's not at all clear why this needs to
> be standardised -- uid 1 has no special meaning as far as I'm aware;
> and user/group bin is easily specified by name.
CPIO format files specify file ownerships by numeric ID, not by name.
(So do old-style tar formats, but the POSIX ustar format extension
added support for using symbolic user and group names.) So for
distributions that want to use cpio as a transport medium, userids do
become an issue.
I don't think this is a major point --- if we had known that this was
going to be a major heartache for distributions, we probably could
have dropped the requirement for user/group bin and simply warned
ISV's to not use CPIO format files with user id's other than zero.
That may yet be something that could be discussed for LSB 1.1.
> It's not clear why operator/root is listed as an optional user/group
> combination. Since they're optional, it presumably doesn't matter
> what the group is, so it would be more consistent to have an
> operator group. Further, it's not clear what the point of specifying
> this is: since they're optional, ISV's can't depend on them being
> present, and thus can't use them.
Good point. Does anyone recall what rationale was for mentioning the
operator group?
> Why are runlevels specified? If I choose to run a system that doesn't use
> runlevels, why should ISV's software break? If I choose to give different
> meanings to the first 6 runlevels, why should ISV's software break?
This has already been answered, but the main reason is to deal with
> It would probably have been a helpful test if there'd
> been some downloadable sample LSB apps (hello_1.0_i386.lsb,
> lsb-test-suite_1.0_i386.lsb) and the appropriate LSB support software
> for various major distributions (lsb-support-redhat_1.0_i386.rpm,
> lsb-support-debian_1.0_i386.deb, lsb-support-slackware_1.0_i386.tgz)
> so that they could be installed and removed and such, just as proof
> of concept.
We're working on the sample applications (and LSB development tools
and a sample implementation), and a number of the various
distributions have already been making changes to their upcoming
released so that they will be LSB compliant. (For example, the
runlevel change was finalized over a year ago, so a number of
distributions have been moving to harmonize themselves with the
standard even before it was formally released.)
One of the reasons why we haven't made a big P.R. splash and haven't
started pushing the LSB to ISV yet is because there's still work do be
done. It's only the written specification which has been done, and we
know there's stil more work ahead.
Volunteers to help add LSB support for Debian would be wonderful, if
you could find any takers. And if there are other sections of the LSB
which turn out to be hard to implement, or where the LSB is
inconsistent, let us know, and we can try to fix it in the next
release.
Already I've received one errata from SuSE when they tried to
implement the final version of the init scripts specification, where
we failed to remove error code 7 (program already running), when we
changed the specification to state that it shouldn't be an error to
call "/etc/init.d/foo stop" if foo is already stopped. So that (since
it's a a simple typographical error) will likely be fixed in LSB
1.0.1. Substantive changes will require more discussion and
negotiation, and will probably have to wait for LSB 1.1, but they are
certainly possible.
- Ted
Reply to: