On Mon, Jun 17, 2002 at 08:52:19PM -0400, Theodore Ts'o wrote:
> The reason why we didn't require lsb script names to be named
> something like lsb-<foo> or foo.com-<bar> was the acknowledgement that
> system administrators *do* type /etc/init.d/<foo> to start and stop
> services, and it seemed unfair to require non-distribution packages to
> need to type something longer and more heinous. (Although granted,
> /etc/init.d/lsb-oracle isn't *that* bad...)
TBH, I wouldn't be surprised if ISV's preferred having something like
/etc/init.d/oracle.com-dbbackend
/etc/init.d/oracle.com-sqloptimizer
(or whatever) to keep their brand name obvious and to have all their
stuff grouped together. /etc/init.d/or[tab]db[tab] is pretty easy too.
YMMV.
> The assumption is that LANANA would registered all of the script names
> used by distributions, and reserve them as "reserved for
> distributions", so that LSB applications wouldn't conflict with
> distribution-used init.d names.
Yeah. The main problems with this is that, at least in Debian's case,
there are so ridiculously many of them, and that in general, it's
not clear what "allocating" them means: you can still get conflicts
between distribution provided /etc/init.d/apache (apache.deb/rpm) and
an independently provided /etc/init.d/apache (lsb-apache.lsb, or even
lsb-ibm.com-apache).
> I assume the 114 script names that conflict with the LSB guidelines
> are the ones which use the '-' or the '.' characters?
That and uppercase. None of those that have a "-" have a "." in the
section before the first "-", though, which means you could easily
allocate:
* ([^-]+\.[^-.]+)-.* to "you", where $1 = your domain name
* lsb-.* to LANANA
* everything else to the distribution
without introducing any conflicts with any existing Debian init.d scripts.
> This is a change, though, and it's not at *all*
> clear to me that we should make such a fundamental change the last few
> days before LSB 1.2 freezes.
Well, this is the review period for LSB 1.2, it's not clear when else
we should propose changes for it. It seems a bit... contradictory... to
have a review period at a point when changes can no longer be made. :-/
Reasons we should change it now rather than for LSB 1.3? Well, it looks
highly likely that the LSB 1.2 spec will actually be adopted somewhat,
so this is probably our last chance to have no risk of changes impacting
application vendors.
Further, if this change is made, in practice it'll probably be a lot
easier to back it out in LSB 1.3, than to leave things as they are now
and make the change in LSB 1.3. You won't harm any vendors by saying
"As well as using /etc/init.d/lsb-foo, you may now use /etc/init.d/foo."
There's some risk of having distributions add new /etc/init.d/bar scripts
in the meantime, but I wouldn't bet on that being particularly reduced
in the short term no matter what the LSB says. It'll also reduce LANANA's
workload: rather than having to deal with distributions requestion bunches
of assignments, it'll only need to deal with application vendors doing so.
I understand a need for a strong justification of any significant change
at this point, but I believe this qualifies, and that it can be better
justified than the existing spec.
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.
``BAM! Science triumphs again!''
-- http://www.angryflower.com/vegeta.gif
Attachment:
pgpm8XJcw4s8h.pgp
Description: PGP signature