proposal do disallow syncs of library packages from experimental without approval

[Steve Langasek]

On Wed, Oct 05, 2011 at 04:17:43PM +0100, Iain Lane wrote:
> On Wed, Oct 05, 2011 at 03:55:54PM +0100, Colin Watson wrote:
> > […]
> > > All three cases have in common that the packages were left alone for
> > > months. The third example could have been avoided if we could check
> > > build dependencies when syncing, and rejecting the sync when the
> > > b-d's are not fulfilled (although there should be an override
> > > option).

> > I don't want to add extra archive-admin checking to the sync process;
> > firstly, we're moving towards self-service syncs anyway, and secondly,
> > as the libav example shows, syncs aren't really special here.

> > More discipline for library upgrades would indeed be a good thing.
> > The main problem seems to be library upgrades that don't really have
> > anyone looking after them (and this is worst when it's Ubuntu-local or
> > from Debian experimental; at least in unstable the Debian release team
> > usually cares to some extent).  IMO, we should make it clear that if
> > you sync or merge a library from experimental then it is your
> > responsibility to ensure that all reverse-dependencies are ported.

> Right: if you introduce a SONAME bump (or similar) you should care for
> it. This cycle the burden has fallen upon those who choose to care for
> the NBS list, and that's neither fair nor sustainable.

> Most of these uploads will have to go through binary NEW so that is a
> good opportunity to check with the uploader that they plan to address
> the ramifications of the uploads they introduce.

I don't think this is something archive admins should be expected to do;
it's not in keeping with the other kinds of archive consistency checks
they're responsible for.  It's also, in a sense, too late - by the time the
package hits binary new, the source version is already in the archive, so we
have to "deal" with the transition in one way or another.

Like Scott, I think this needs to be the responsibility of the developer
starting the transition, and this is true regardless of the origin.  I think
the point of starting this thread is to get a consensus that this is the
right way to handle transitions and to *raise awareness* of the issue, with
a particular emphasis on experimental because pulling in a transition from
experimental means we effectively have no backing from the Debian
maintainers for getting it done in a timely manner (i.e., within an Ubuntu
release cycle).

So I would be in favor of requiring folks to discuss on ubuntu-devel any
proposals for pulling libraries from experimental...  in general, but
particularly for the LTS.

This is certainly not a hypothetical, btw.  libevent was synced from
experimental to oneiric to support a new version of transmission, and this
resulted in a lot of extra work this cycle to fix up the many build failures
among the reverse-dependencies - including of honeyd, which is by the *same
upstream author* as libevent and had not been ported to the new libevent API
(and won't be any time soon).  In the end this was resolved by introducing a
new source package for the previous upstream version of libevent.

We clearly aren't all on the same page today regarding how transitions
should be handled in Ubuntu.  Hopefully this thread will help us get there.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20111005/2e1b5496/attachment.pgp>