Robert W Current, Ph D <[EMAIL PROTECTED]> writes: > I have been a UNIX user for over 6 years now. I have followed the > LSB since before there was a LSB. I have seen it get tons of press, > have great ideas, and fade slowly into the background. I think it's > time for a swift kick in the rear end!
Hi Rob. Is that an offer to help? There is now an LSB task list located at 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. > 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. > Third, although I believe .tgz, .deb, .rpm, and the like are something > the LSB shouldn't endorse, I do feel that how these packaging systems > interact with what is "a LSB Compliant System" must be addressed. This > can NOT be avoided. THINGS MUST CHANGE! > > Packaging systems must be free to develop on thier own, and do thier own > thing. BUT, most likely, all of them will have to be "adjusted" so that > they fit within the scheme of what it is that the LSB is trying to > address. I'm not sure if you agree or disagree with me. > And, finally.... IT'S BROKE! Yes, IT'S BROKE! We MUST FIX IT. No "if > it ain't broke, don't fix it" stuff applies. There is an absolute need > to change some of the fundumental underlying structure of what "Linux" > is... "Linux" must be DEFINED! You could also use the word "documented" instead of "defined". Actually, I don't think you're disagreeing with our current approach very much. Have you looked at the draft specification? 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
