Re: Multilib Middle-Ground

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

 



Patrice Dumas wrote:

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.

And not to follow upstream changes? This is not good for fedora.

Why? You have no qualms about trying to influence what proprietary vendors do by not shipping things you don't like. Why not do the same where its more likely to make a useful difference?

I
completely agree with you that incompatible ABI changes are hurting
free software, but this should be fixed upstream, and not in linux
distros.

But as long as you keep shipping things without backwards compatibility you not only hurt your existing users whose own code will break but you encourage the practice. It's always possible to add new interfaces instead of breaking the old ones if they weren't designed to be extensible.

You could try to approach upstream projects that break ABI
frequently and try to convince them to avoid breaking ABI if you want
to, but fedora cannot do anything else than consuming what upstream
produces.

If you know something hurts, why keep doing it? Why not maintain stable kernel and library versions for long periods with the current kernel and differently-named experimental libs as alternative choices? After some long interval of concurrent use and compatibility testing the no-longer-expermental libs could replace the stable versions.

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.

This is not that different than what is done in fedora. Of course we may
wait for an application that use new features of an ABI modified
application to be needed, but it wouldn't be very different from what we
do now. You could try to push the idea that within a fedora version ABI
compatibility should be kept if possible, but between fedora versions,
I think that it is better to follow upstream.

I think that should depend on what upstream does. Fedora has a fast enough cycle that waiting for the next release for an incompatible change wouldn't kill anyone.

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

What do you propose instead? Not following upstream?

Just not breaking anything that already works. If upstream does that, the distribution has to make a choice between bleeding-edge code and hurting its users. The code will still be there for the next release - and maybe by then it will have fixed its backwards compatibility.

--
  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