Avoiding fragmentation with a rolling release

Michael Hall mhall119 at ubuntu.com
Sun Mar 3 20:26:23 UTC 2013

On 03/03/2013 01:28 PM, Colin Watson wrote:
> On Sun, Mar 03, 2013 at 10:48:21AM -0500, Michael Hall wrote:
>> I agree, it was one thing when we would keep the same version of a
>> library for 6 months at a time, but with a rolling release you could
>> have one library or another being upgraded to a new major version
>> every week. So unless those upstreams committed to
>> backwards-compatibility, all of the work for providing that would fall
>> to us.
> Let's be clear about our thinking on this or we won't get anywhere.  The
> problem is not libraries being upgraded to a new major version.  The
> problem is the older version no longer being provided.  For example, we
> have at least six versions of Berkeley DB in the archive, the oldest of
> which I added to Debian in 2002 in order that old versions of a certain
> proprietary web server would keep on working; there's been no reason to
> ever remove it since then, as it accounts for very little maintenance
> effort.  This is not rocket science; it just isn't worth doing unless
> there's a specific motivation.
> In general, we clean up old versions of libraries after their SONAMEs
> change because it saves on scarce maintenance effort, package index
> download time, and things like that.  But that doesn't mean that we
> couldn't go to some special effort to keep older versions around in
> cases where we've made some promises about them.  If we actually had a
> documented list of cases where we cared about compatibility - or we
> could even generate this after the fact from app metadata - then we
> could ensure that all the relevant packages are still available in the
> next LTS, and document their obsolescence so that app developers know
> they need to move on.
> This accounts for the vast majority of cases.  There's a smaller number
> of cases where semantics change incompatibly, and we'd need to pay
> attention to those on a case-by-case basis; but I think this is a much
> smaller and probably more tractable problem.

>From an app developer's perspective, I would be happy with this
solution.  If it wouldn't add an unreasonable amount of added effort or
resources, then I think it is something we should do.  At the very lease
we need to cover those APIs that we consider part of the overall Ubuntu SDK.

Michael Hall
mhall119 at ubuntu.com

More information about the ubuntu-devel mailing list