RFC

[Robert W. Current, Ph.D.]

Daniel Quinlan wrote:
> 
> Hi Rob.
> 
> Is that an offer to help?  There is now an LSB task list located at

Absolutely. :-)  I'll have to start cetching up on the archives, and
join the other lists.  I'll look into it tonight.

>   http://sourceforge.net/pm/?group_id=1107
> 
> The list is not finished yet, but between it and unfinished parts of
> the spec and stuff that the test suite doesn't cover, there's enough
> work to be done.  A small number of people are concentrating on that
> work and we're working on increasing our manpower.

I'll look.  I definatly don't agree with the spec as I have read it
last.  The OS does NOT include X, X is software.  I think the LSB has
drifted way to far into standardizing software, and not defining a
"base" OS.  X is one example of a huge hunk of software, that is fairly
standard, but should be considered "software" and not the OS.

X standards should be in place somewhere, but I think it should be spun
off into it's own project, and not part of the LSB.  I think there are
too many problems to be addressed before X is considered, and it's just
taking on too much responsability.  Plus, I firmly believe that MOST
Linux servers in use today (commercially) can operate perfectly without
X, providing proof that X need not be included in the "base."
 
> > Second, any issue of "software packaging" should NOT be standardized
> > by the LSB.
> 
> It does need to be handled (at least the binary package format) by the
> LSB because 3rd party application vendors need to have a way to
> deliver their software to LSB-compliant systems.  For now, the format
> is .rpm since everyone supports it.

It shouldn't be defined.  I have looked at that over and over again.  I
think I initally said it should, and I was wrong.  I know everyone wants
it....  But that's not part of what a "Base Linux System" should
include.

If your going to define something, don't just "standardize" something
that is in use, make a logic based standard.  Like, say where packages
should install to, and _maybe_ go so far as to say what the "package
inventory" lists should be, and where they should be stored.

Trying to get everyone to use one packageing method is a hurdle that's
going to waste more time than anything else, and if all the other
details (where software is installed, and maybe where/how the inventory
is kept) will then allow all packaging systems to work together on one
system.

The spec should be more flexable to ISV's and distributions.  The hard
part that should be focused on is making it all work, and with a
properly defined installation location and tracking method, packaging is
irrelevent.  This will mean all packaging methods will have to conform
(==work), but no packaging method is treated indorced or standardized
(==fair).

> You could also use the word "documented" instead of "defined".

Yes, you could say that.  LSB should be a "document" not a system.  It
should just be a spec that LSB compliant systems conform to.

The test suite should just test if a system conforms to the spec, not 
 
> Actually, I don't think you're disagreeing with our current approach
> very much.  Have you looked at the draft specification?

http://www.debian.org/Lists-Archives/lsb-spec-0002/msg00015.html

I strongly disagree with this (maybe it's too much BSD in my blood).

I don't think that /etc/* should contain _all_ of anything. 
/usr/local/etc/ should contain most of the stuff, and have init levels
been definded yet at all?  They need to be.  Using RHS ones (which I'm
not sure I agree with) I would say:

Oh, just found it...
http://www.debian.org/Lists-Archives/lsb-spec-9904/msg00005.html

Only 3 and 5 should read /usr/local/etc/init.d/, and the others use
/etc/init.d/ 

level 1 definately should not load /usr/local/etc

> Also, this list doesn't get much traffic.  It's mostly on lsb-spec,
> our meetings, and biweekly LSB specification conference calls (see the
> talks web page).
> 
> Dan
> 
> --
> To UNSUBSCRIBE, email to lsb-discuss-request at lists.linuxbase.org
> with subject of "unsubscribe". Trouble? Email listmaster at lists.linuxbase.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: current.vcf
Type: text/x-vcard
Size: 377 bytes
Desc: Card for Robert W. Current, Ph.D.
Url : http://lists.linux-foundation.org/pipermail/lsb-discuss/attachments/20000315/26a99007/attachment.vcf