Re: LSB on /.
As moderator of the "Lowest Common Denominator" packaging taskforce I feel
the need to jump in here.
Dave Greene wrote:
>
> I figured since I've been quite and reading for awhile, I might as well
> throw my 2 cents in regarding the LSB.
>
> I'll go threw each topic, and add some of my thoughts/opinions, as an end
> user, and someone who maintains systems.
>
> So, lets get on with it.
>
> On Tue, 8 May 2001, Me wrote:
>
> > > The LSB 0.9 announcement is on /.
> > >
> > > http://slashdot.org/article.pl?sid=01/05/08/1412223
> > >
> > > Please do respond to posts with questions.
<AdH snip>
> > 2. They picked RPM. They're red hat droids.
> >
> > "it appears both redhat and debian are
> > contributors, but i would imagine redhat
> > contributes a bit more. i really think this is
> > going to hurt things."
> >
> > [I pointed out there had been plenty of debate.]
> >
> There have been lots of debate, and personally I can't stand RPM's to any
> degree what so ever, and don't believe that it's the answer. As was
> stated in another RPM debate thread that is going on at the moment.
Bad experiences with packages in RPM format seem to have warped lots of
people for life. Therefore we are going to reuse the best bits (the
archive with metadata format) and hide that behind *.lsb filenames. :)
Most of the bad experiences seem to come from naively attempting to install
RPM's from one release on another. Then RPM is blamed for a release
consistency problem. Since the software installed in *.lsb's will be
verified against LSB requirements (i.e. the LSB release) then we hope that
the release consistency problems should be much smaller. The spec keeps
track of the release, the packager installs the compliant apps on compliant
distro's
> "Let's face it, RPM is far from ideal. It has flaws. Different Linux
> distributions implement different features in RPM that essentially, from
> the ISV perspective mean that to support just the commerncial Linux
> distributions requires the same effort as supporting 5 or 6 different Unix
> implementations. The cost and overhead of this is not worth it to many
> large software houses. In other words - we all lose out!
We hope to eliminate the problem by specifying the limited set of packaging
constructs that can be used in *.lsb packages. We are starting with the
intersection of dpkg and rpm.
> The LSB had to start somewhere. We recognise that we are not going to
> convert all the RPM based Linux distributions to deb. Not yet that is, and
> probably not at any time soon. "
>
> As stated by John H. Terpstra. However, if it's not worth doing right in
> the first place, why bother? Not to insult RPM itself (I personally don't
> like it, but that's my opinion), but, why rush the LSB out the door if
> it's not ready?
To gain real experience? To get something out the door in a short time
frame? Vapourware is hard to use?
> Other then trying to hurry the LSB out the door at a
> previous point (at this juncture in the road, I believe the debate is
> mute, and I am not trying to start it up, nor continue it), wouldn't it
> have been better to define a new set of API's, and then someone else could
> build it? As it is, I don't see that distributions will be able to
> implement the LSB as it runs out the door.
>
> >
> > 3. They didn't pick font standards.
> >
> > In this thread, one poster completely misunderstood
> > what it meant to have a "standard base".
> >
> > "ghostscript and X fonts are very different and
> > used for different purposes. I don't see a reason
> > to combine them into one."
> >
> Is there a specification for type setting now in the LSB??
>
> >
> > 4. Reversing Linux fragmentation is a good idea.
> >
> > A more intelligent poster said:
> >
> > "My question is, is it not so much that we're
> > making it so all software can run on many
> > distributions, as making all distributions
> > essentially the same?"
> >
> Personally, and this is personally, are we making all distributions
> essentially the same? If that is the case, why not just go back to using
> Microsoft products?
AFAICT the LSB is mandating what "things" must exist and how they should
work. As long as that is satisfied then any and all extensions are fair
game. ISV applications cannot easily depend on distro extensions though :)
> > 5. It should be GNU/Linux Standard Base.
> >
> > Most posters debated what the name really
> > should be:
> >
> > "Standard Base for Systems Built Upon a
> > Linux-alike Kernel"
> >
> I'm staying out of the GNU/Linux debate. I call it Linux, but then, I
> refer to the Kernel, I call it slackware because that's the distro I use
> and refer to.
>
> >
> > 6. Why did Slackware boycott the LSB?
>
> As mentioned in a few posts scattered about, the RPM settlement was a
> given, as just about everyone represented here uses the RPM format.
> And, I believe that slackware prefers to be uniquie in it's own way.
>
> Personally, after reading some of the Rationales, such as the Further
> Rationale item 1. which states:
>
> "1. We need to develop a single model Linux system. One that can be
> adopted by the various distributions with little difficulty. This is the
> single greatest goal that we must achieve. Anything which interferes with
> this goal should automatically be eliminated."
>
> It sounds more like "Resistence is futile, you will be assimilated". As
> far as I was aware, and the great thing about Linux, is it's diversity
> (though, that has gotten abit out of hand here and there). In Item 4, it's
> stated not to dictate what linux can do now, and let linux go where it
> goes, except some of that will be stiffled by say a new distro xyz (lets
> say I made it) that has implementation of a new thing, but also wants to
> be LSB compliant, it's either install backwards compatability in one form
> or another, or abandon it.
I can't imagine a feature this cool that would make LSB conformance
complete inpossible. The LSB spec is generic enough that it would be
really hard to come up with such a feature without making the concept of
binary portability useless anyway.
> Yes, the option to have 2 "items" (I'm using
> items because I have no current examples at the moment) reside together is
> always there and possible, But if 1 system is far superior to another,
> then why even bother with the inferior one. This would be a possible case
> of the LSB not updating fast enough, but, in the public eye, does it
> really matter if xyz distro is not at fault, and has something superior.
Please allow the LSB to evolve to match new and useful concepts as they are
proven. Dreams and "what ifs" are not proven in my books.
> These are all just my opinion, and maybe I missed something here, or
> failed to read into something far enough, all comments to me personally
> are welcome, however, as I have seen things unfold from my seat, it seems
> as if the LSB is following the Microsoft legend, in some cases they have
> had good ideas, but with poor implementation, or gestapo like tactics to
> force something that could have possibly been good on it's own merit (no
> examples here, if you have any, I'm interested).
>
> I think the LSB is a great idea, but can be stiffling to some distro's
> (did I mention I use slackware?). One of the things I'm actually curious
> about though, is an example of pre-compiled software that was not
> installable and/or runnable from one distro to another, as in my travels,
> using mostly source, I have not had this problem, nor encountered it
> anywhere.
My biggest stubling block has been that what names and versions mean in the
dependency databases of the various distros varies enough to be useless
when building packages. Beleive me, I built the Corel WordPerfect Office
2000 Packages and know what I am talking about here.
Anything built on a libc5 system and today's glibc (ABI
incompatibilities). Anything that attempted to be smart and depend on
libc6 (RH: O.K., MDK: not, Debian: maybe SUSE: Not). Anything that depended
on grep being installed for the installation scripts to run properly so I
could dodge around dependency inconsistencies. The list goes on....
> -- Dave Greene
> Dave.Greene@omniplex.net
>
> >
> > --me
> >
--
Albert den Haan, Lead Developer @ Linux Port Team . Corel Corporation
albertd@corel.com (613) 728-0826 x 5318
--
The address in the headers is not the poster's real email address. Do not send
private mail to the poster using your mailer's "reply" feature. CC's of mail
to mailing lists are OK. Problem reports to "postmaster@umail.corel.com".
The poster's email address is "albertd@corel.com".
Reply to: