Proposal to reduce anti-bundling requirements

[Andrew Haley]

On 10/12/2015 04:29 PM, Kevin Kofler wrote:
> Andrew Haley wrote:
> 
>> On 10/10/2015 12:12 AM, Kevin Kofler wrote:
>>> Then you try to port the application to the new APIs, and if it's not
>>> possible, you revert the library commit that removed the old API.
>>
>> Well, hold on: you now have the problem of maintaining a local fork.
>> Surely that is more than a package maintainer should have to do.
> 
> I disagree. This kind of integration patches is what a distribution
> is for to begin with. If users wanted to use vanilla upstream
> tarballs with no modifications whatsoever, they'd use LFS. (And in
> practice, even LFS has patches they make you manually apply, because
> the tarballs won't even COMPILE together as is.)

Hmm.  I suppose, then, it's a matter of degree: just how much of this
porting work can people do for a distro?  I understand your point, and
it's defensible enough from a principled point of view.  However, it
requires a packager to be a fairly expert developer of what they
package, and to have time to do it.  I guess most libraries aren't
so bad that it's a huge problem.

My instinct is to agree with you because stable APIs are pretty much a
prerequisite for a stable operating system: you can't build anything
solid on shifting sand.  But all distros are, in the end, no better
than their upstreams, and API stability is only one aspect of quality
and reliability.

But sometimes an API changes because a library has been refactored;
and it may not even be possible to provide the old interface because
an entire class of functions has been removed, perhaps for a very good
reason.  But that argues for versioned libraries, not bundling, even
if a library is only used by one package.  At least that way the
package gets tested with the library version it was built with... but
then we end up with version hell if two libraries need different
incompatible versions of libXX.so, and some package uses both of them.
Argh!  There's no simple way to do it, and no rule that will fix it.

Andrew.