Hello world,
Some comments, probably all negative. I'm quite aware you'd rather these
have been sent in before 1.0, but well, life sucks. I'd've rather'd 1.0
only come out once you'd made sure Debian was compliant too. But, well,
life sucks.
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.
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.
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. 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.
There further doesn't appear to be a policy on what users/groups an LSB
package is permitted to add. Can they add anything, and if so, what happens
if it conflicts with the name of a user on the system?
Why can't ISV's rely on /proc being mounted?
LSB compliant packages have to "adhere to the FHS 2.2". Does this
mean they should put their files in /opt and /etc/opt? Or just that
they can't put them in /FooCorp? If they have to put them in /opt and
/etc/opt, should they install symlinks in /usr/bin so you can easily
use their program? Would it be better to specify /opt/bin and recommend
LSB compliant distributions include that in the default path? If we're
using /opt for most stuff, shouldn't there also be an /etc/opt/init.d
directory for LSB packages' init scripts, so they don't step on the toes
of init scripts from the distribution? This would allow LANANA to have
somewhat freer reign in giving out names and such for init scripts.
Why is it expected that applications will need to write to
/var/mail/<username>? Should, say, OpenOffice.lsb fail to work because
I put my mail in ~/mail in maildir format?
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?
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.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``_Any_ increase in interface difficulty, in exchange for a benefit you
do not understand, cannot perceive, or don't care about, is too much.''
-- John S. Novak, III (The Humblest Man on the Net)
Attachment:
pgpz_19H14akN.pgp
Description: PGP signature