Multilib Middle-Ground

[Patrice Dumas]

On Fri, May 02, 2008 at 02:04:58PM -0500, Les Mikesell wrote:
>>
>> 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?

If fedora doesn't use the latest upstream release it hurts Fedora, not
upstream. (and I have absolutely no opinion about 'influencing what
proprietary vendors do', it must be sommebody else who said that).

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

We cannot encourage or discourage upstream. We are downstream. Even RHEL
don't care (unless I am wrong) about ABI compatibility between releases,
it would be too much work.

In fedora you can always do compat packages if you like.
I would happily review them. I have always been opposed to the
'and the primary package maintainer is not against the idea' in
http://fedoraproject.org/wiki/BrianPepple/DraftCompatPackages
(though I agree with the remaining). So nothing is stopping you to
provide old sonames in fedora, except for the amount of work (and maybe
primary maintainers disagreeing, but I hope that it won't be a real
issue). But backporting bugs from maintained releases to compat release
unmaintained upstream and only maintained in distro is a lot of work.

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

It is possible to do the reverse, that is ship compat packages, it is
even possible to ship old API. For example I maintain in parallel libnet
and libnet10 for quite a long time now (both versions are unmaintained). 
I cannot do that for other libraries I maintain (notably libdap) it
would mean too much work (in reality, I have to do it more or less for
EPEL, but in that case somebody else commited to do the backports, since
I won't do it).

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

I am personally in favor of that, that is, try to wait for rawhide to
break ABI, except if there is a security issue in old lib, or a very
problematic bug, and backporting is not easy. There has been
disagreement in the past about that issue. I hope that having bodhi now
reduces the amount of ABI breaking in updates.

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

I have never seen an upsteram breaking ABI reverting to a previous
soname because ABI unbreaking happening later. In libdap there are
frequent API/ABI breaking but I have no choice other than accepting these 
changes (between fedora releases) because dependent software always use 
the latest API.

--
Pat