Chapter 13 again ...

[Evan Leibovitch]

On Wed, 19 Jul 2000, Anthony W. Youngman wrote:

> >5)  Yes, we know that RPM's aren't necessarily compatible across
> >    distributions.  The way that we will address this is by strictly
> >    limiting what dependencies a RPM can have.  The only dependency that
> >    it can assume the system will have will be something like
> >    "LSB-1.0".  (i.e., no libext2fs, or libc6.0, or other dependencies
> >    which unfortunately arne't standardized across distributions.)
> >    For compatibility reasons with Debian dpkg systems using aliens, we
> >    will also sharply restrict what kind of trigger scripts can be
> >    included with such RPM's.
> >
> This is what I was trying to address. Because you can't guarantee what
> will be there, you are guaranteeing a minimal subset of out-of-date
> libraries. If the LSB had been released 6 months ago, it would require
> libc5, but most distros are now glibc2.1 based. If it was released today
> it would require Xfree3, but in 6 months distros will HAVE to be Xfree4
> based - new hardware and drivers will force their hand ... (that's
> probably a slight exaggeration, but you get my drift).

Every standard, to one extent or another, can be argued as an impediment
to innovation. The whole point the LSB is trying to address is to give
software developers a target that isn't moving quite as rapidly as the
bleeding edge.

Does this mean that a standard such as the LSB _can_ have the effect of
being a lowest common denominator? Sure. But the related benefit is
considered worthwhile to many.

An LSB-compliant system need not limit itself to the facilities required
by the spec. It must simply guarantee that the facilities are there,
possibly alongside more-recent releases.

> In other words, as it now stands, the LSB will either act as a major
> brake on innovation, or be widely ignored. I suspect it will be the
> latter :-(

I suspect you misread the mood out there.

Demand for the LSB is extremely high; its greatest threat is that the
outside community will simply give up waiting for it. The problem is not
one of this or that library, it's a real possibility that a substantial
number of developers will internally declare the LSB irrelevant, simply
target a specific distribution (likely what they see as the 'leader'), and
hope that the others can make themselves compatible enough to run it.

We already have examples of this, as in "Code Warrior for Red Hat". My
greatest fear is that if the LSB goes much longer without any kind of
public deliverable, more and more developers will do this. The end result
is that "the standard" will evolve into whatever Red Hat puts in a given
release, warts and all, and the other distros will likely have to have
"red hat compatibility" packages.

This would not be far different from the Unix-on-Intel situation of a
dozen or so years ago, when SCO was the leader and all the other
implementations (Interavtive, Esix, Dell, AT&T) had to have "SCO
compatibility packages" to allow them to run SCO binaries.

Now, like then, there is heavy demand for *a* standard; all that's at
issue is how the standard is defined. Is it a community-wide effort, or
does everyone just play catch-up with what Red Hat puts in its next
release?

Fact is, most of those who want a standard don't really care where it
comes from. Many commercial developers are just fine with the idea of
deeming Red Hat the 'defacto standard' whether users of other distros like
it or not. They'd *prefer* if everyone was in sync with a single neutral
spec but their patience is finite.

> "The only dependency that it can assume the system will have will be
> something like "LSB-1.0".

... which itself would use appropriate dependency mechanisms to ensure
that all components required by the spec are installed before the system
can respond that "LSB-1.0" is available. The "LSB" pseudo-package could
conceivably contain very few files of its own.

> While I may not be going about it the right way, the problem I am trying
> to address is "I need XFree4 and I need it NOW. Is it there?"

That's not how it works.

A develper will create software compiled using certain libraries and
making certain assumptions about the underlying system. The LSB
(pseudo-)package will guarantee to a compliant app that the necessary
libraries are available and the assumptions will be valid on the runtime
system.

> If I need technology that post-dates the most recent LSB, then I'm
> stuffed as things currently stand :-(

You're not stuffed, you're simply non-compliant. You can't be bleeding
edge and standard simultaneously, almost by definition.

It's anticipated that the LSB spec will be updated at regular intervals so
that an LSB-2.0 might specify newer releases of some components, and
others which didn't exist at all in 1.0.

> I HAVE to provide rpms, and I HAVE to trust that the distro's default
> package manager will "do the right thing". It's all very well putting
> "requires LSB 1.2 *and* libs x, y and z" on the box, but firstly how
> many people read the documentation, and secondly how many people would
> understand what it meant.

You could use the package manager's dependency facilities to require
them at install time. If I recall correctly, dpkg can even automagically
load dependencies if they're not installed.

> You may disagree with me, but I don't think a "guaranteed minimum
> system" is that important.

While non-commercial developers aren't as interested, the marketplace
disagrees with you, big time.

> What I think should be addressed (and is being completely ignored as
> far as I can see) is "what does this system ACTUALLY HAVE". That
> latter is certainly the be-all and end-all for bleeding edge gamers,
> and probably many others too.

LSB is trying to solve a specific problem -- it doesn't look like it can
solve yours. But that does not make it useless. Not everyone demands
bleeding edge. And you can't be all things to all people.

> I'm looking at it from an "experienced user" position.

No you're not. You're looking at it from an 'early adopter' position,
experience has nothing to do with it.

Most Linux users are quite happy using releases half a year old or more
providing they work, their security is addressed, and they're supported by
an organization larger than someone working out of his basement.

> Consider the following scenario - I have a 1Gb program I'm selling.
> The most recent LSB is a year old, and has been invalidated by
> bleeding-edge distros :-(

You can stop the complaint there. An LSB spec, once widely accepted, will
never be invalidated. It may be superceded, but it's certainly conceivable
that people will make apps against LSB-1.0 long after LSB-3.0 is released.
I don't think it's a stretch to suggest that the vast majority of
developers don't care about being on the bleeding edge. For every games
coder there are a dozen doing databases for dental offices that don't
really care about the release of XFree on the target systems.

> I want to be able do a 100Mb minimum
> install, and it's a pretty safe bet a large proportion of my customers
> are lusers.

If they're lusers then they won't be using the bleeding edge distros, will
they?


-- 

Evan Leibovitch, Brampton, Canada <evan at telly dot org>
Anything not worth doing is not worth doing well.