Les Mikesell wrote:
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.
Cause there is no good definition for "long periods". So if some
arguments make Fedora to change the "old things" only for a new release
the same arguments will also tell to preserve compatibility from release
to release. And that's a bad way to go, cause compatibility issues made
Microsoft keep "compatible" (read: old, weak, dumb) LM hashes from Win
3.1 till Vista (http://en.wikipedia.org/wiki/LM_hash). And Microsoft did
it cause it was forced by it's partners, ISVs. Even RedHat had to keep
old LinuxThreads (old, bad threading library) cause it needed to be
compatible.
One of the most important things I (and maybe many people) like about
Free Software and Fedora is that You aren't dependent on ISVs. If I
wanted an OS which is compatible from version to version, I would be
using Windows.
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.
Well this is mostly true, but we would soon get people who would say
"Why does Cool_app_X work with Fedora 9 but doesn't with Fedora 10?
Fedora 10 is OBSOLETE/BAD/EVIL. If You don't make Fedora RUN Cool_app_X
I'm gonna switch to Windows."
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.
After breaking backwards compatibility nobody usually cares about fixing it.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
