Multilib Middle-Ground

Les Mikesell lesmikesell at gmail.com
Fri May 2 19:04:58 UTC 2008


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 at gmail.com





More information about the fedora-devel-list mailing list