'lo,
So, some review, presuming this list is still active. First, let's start
with my bugs from last time round.
Issue 496592, UID for user/group "bin" should not be specified: fixed!
Issue 496595, Run Levels Are Unexplained: fixed!
Issue 496598, How init scripts may be named is not defined: not-a-bug
Issue 496599, Example for install_initd uses badly named init script: fixed!
Issue 496600, LANANA/LSB should not attempt to take over /etc/init.d:
closed but not fixed, further discussion below
I think that covers the bugs I filed, this time round, and that's a damn
fine hit rate. Very cool. It might've been nice to have been emailed about
it (the review form for 1.1 encouraged you to include an email address,
IIRC), but *shrug*.
On with the review proper, starting in section VII, chapter 14, Software
Installation.
As discussed previously on the lsb-discuss list by Joey Hess and Erik
Troan (the maintainers of alien (which is the tool Debian will use to
install LSB packages) and rpm [0] the Package Format section should
be changed to indicate that the first two bytes of the RPM reserved
header should be set to some non-zero value to indicate that this is an
LSB package.
In chapter 18, File System Hierarchy, it'd probably be a good idea to give
"/opt" more emphasis than "An LSB conforming application is recommended
to follow the FHS 2.2. If it does not follow the FHS 2.2 it should
include documentation of the differences." LSB applications should,
AIUI, reside almost exclusively in /opt and /var/opt (with /etc/init.d/*
being the only exception?). ATM, the only place this is clearly stated,
afaict, is in the LSB pilot programme pages.
In chapter 19, Recommandations.../File write permissions, it'd probably be
better to allow /var/mail/<username> not to be writable, so that systems
which use ~/Maildir or IMAP exclusively can be LSB-compliant.
In chapter 22, www.lanana.org is referred to, but that site doesn't have
any LSB related stuff yet. In the same chapter, at least in the HTML
version, "runlevels.html" has a typographical error: "section /Comment
conventions for init scripts>/" probably shouldn't have an angle-bracket.
Still in chapter 22, Facility Names, it's not clear what value $local_fs
provides. It seems entirely possible that $local_fs could be satisfied
with only / available, without /opt, /usr, or possibly even writable
/tmp or /var/tmp (which is to say, all of those directories could be on
remote filesystems). Especially considering no LSB package can ensure
it's run before any of the system facilities, it seems the most reliable
implementation would be to run all LSB init scripts after all system
facilities have been made available, which makes specifying them fairly
pointless. Oh well.
In the same section, there's a typo: "using the same conventions defined for
naming init.d script names." -- the last word shouldn't be there.
In the next section, Script names, I'd like to again suggest that LSB scripts
be named either:
* lsb-<foo> for LANANA allocated names
or * foo.com-<bar> for names based on the DNS
and the remaining namespace be reserved for distributions. This certainly
won't cause any more conflicts with existing practice than the existing
language does, and doesn't seem too much of a burden to place on
LSB application vendors. Further, it allows LSB packages to coexist
with distribution provided packages (/etc/init.d/apache from Red Hat,
/etc/init.d/lsb-apache from the apache group) on the same system should
the sysadmin so desire.
The real reason I think that's a better way of doing things is that
otherwise Debian needs to register some 350 init.d script names [1],
and needs to worry about an additional 114 that conflict with the LSB's
guidelines. Personally, I think we should avoid this conflict while
we can. (For reference, there are about 40 pre-allocated names listed in
the spec at the moment)
In particular, if this suggestion is going to be rejected for LSB 1.2,
could this please be considered a request for LANANA to allocate the
names listed at the URL in the footnote?
Neato, that's it, as far as I can comment.
Two other matters. One, is that a two-week review period is _very_
short, especially when, afaik, no one outside of the LSB core team have
had much of a chance to review the changes as they happen. The other is
a changelog would be really helpful: it's too easy to skim over minor
wording changes that could mean important things without them.
Can anyone indicate if a review in this format (a single email to this
list) is adequate, or if I should file the above remarks via the review
interface as well?
Anyway, well done, it's very nice to see almost all of the bothersome
issues from last time fixed up. :)
Cheers,
aj
[0] Starting at:
http://lists.debian.org/lsb-discuss/2002/lsb-discuss-200202/msg00020.html
and continuing through:
http://lists.debian.org/lsb-discuss/2002/lsb-discuss-200203/msg00000.html
with the more relevant messages being:
http://lists.debian.org/lsb-discuss/2002/lsb-discuss-200203/msg00007.html
http://lists.debian.org/lsb-discuss/2002/lsb-discuss-200203/msg00008.html
[1] http://people.debian.org/~ajt/woody_script_names.txt
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``BAM! Science triumphs again!''
-- http://www.angryflower.com/vegeta.gif
Attachment:
pgpXN8t0PYuXs.pgp
Description: PGP signature