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
