Re: Multilib Middle-Ground

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Chris Adams wrote:
Once upon a time, Les Mikesell <lesmikesell@xxxxxxxxx> 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@xxxxxxxxx


--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux