Multilib Middle-Ground

[Suren Karapetyan]

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.