Multilib Middle-Ground

Les Mikesell lesmikesell at gmail.com
Fri May 2 15:43:11 UTC 2008


Chris Adams wrote:
> Once upon a time, Les Mikesell <lesmikesell at gmail.com> said:
>> I'd think that a distribution on the bleeding edge as fedora should be 
>> the one leading this effort, not looking for something to join.
> 
> One problem with standardization is that it tends to freeze development
> in some ways.

And encourage it in other ways.

> A big compatibility issue is shared library sonames.  For
> standards to emerge, you'd have to define a complete set of compatible
> sonames.

Yes. Which would amount to each distribution doing less changes.

> That would mean all compatible distributions would have to be
> using (essentially) the same version glibc, gcc, X, GNOME, KDE, perl,
> python, etc. at the same time.

No, it would mean maintaining that standard above with required backward 
compatibility.  You'd only have update libs to match the newest app rev 
you want to run.

> It would require all the major open
> source projects to be synchronized to the same release schedule (or at
> least all distributions to pick up new versions of everything at the
> same time of year).

That wouldn't be a bad thing for linux distributions to do, but I don't 
see how there is any timing requirement inherently tied to providing 
standard interfaces.

> That just isn't going to happen.  For some of these things, Linux
> distributions are a large part of their user base (glibc, GNOME, KDE),
> and you might could work with them, but for things like gcc, perl, and
> python, Linux is only one of many targets.

I wasn't aware that perl had a lot of library version specific 
requirements.  Can't you compile a current perl just about anywhere?

> Usually, if you restrict yourself to building against older versions of
> the libraries (e.g. pick the oldest enterprise distribution you are
> interested in supporting), your program should run with no problems on
> the latest bleeding-edge distributions.

So why isn't it done this way in all cases to get distribution-agnostic 
application versions instead of making people with multiple distros get 
different flavors for each?

> However, they do package it with some compat libraries like OpenSSL;
> that's a library though that has traditionally been one of the worst at
> ABI compatibility in the shared libraries (and there's not much Fedora
> can do about that).  They also include libgcc and libstdc++, also
> libraries that have had a moving target ABI over time.

Just because some developer writes some incompatible code doesn't mean 
distributions have to ship it.

-- 
   Les Mikesell
    lesmikesell at gmail.com





More information about the fedora-devel-list mailing list