Avoiding fragmentation with a rolling release

Colin Watson cjwatson at ubuntu.com
Sun Mar 3 18:28:22 UTC 2013

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.

Colin Watson                                       [cjwatson at ubuntu.com]

More information about the ubuntu-devel mailing list