[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: LSB Spec 1.2 criticism



On Tue, Jun 18, 2002 at 01:17:06PM +1000, Anthony Towns wrote:
> 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.

Or rather the NASDAQ/NYSE/*SE code for their stock (ie. like the "standard"
used on Solaris' packages)
ie. CSCO for Cisco based stuff, SUNW for Sun, etc.

Their would a "problem" for systems/packages that doesn't have their own domain
name nor Stock Code on an SE. ie. SF/Savanah/Berlios hosted projects that
provides installation binaries.


> > 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
 or Stock code as described above.

> 	* 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.

It already become an issue in one or two upcoming distributions that would be
targeting themselves as LSB compliant, as the real intentions and views on
this chapter is quite vague, and open for lots of debate and interpretations.

I for one would like to have it crystal clear as to what must be using which
httpd/syslogd etc. name too.

Eg. is Apache or Tux or Roxen suppose to be httpd?
Should both klogd & syslogd be started from syslogd ?
What about metalog & syslog-ng ?

These are a few of the contentious questions that get's raised by this chapter
that's not quite clear, especially when sendmail & postfix have different
names in this draft.

> 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.

And also to clarify it it beyond reasonable doubt :)

> 
> 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



-- 
To UNSUBSCRIBE, email to lsb-spec-request@lists.linuxbase.org
with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org



Reply to: