Bug#690204: Bug#537051: Add no-await trigger support and Breaks to fix ca-certificates-java breakage

[Guillem Jover]

On Thu, 2012-11-29 at 08:48:04 -0800, Don Armstrong wrote:
> On Thu, 29 Nov 2012, Guillem Jover wrote:
> > On Tue, 2012-11-13 at 13:18:37 -0800, Don Armstrong wrote:
> > > diff --git a/debian/ca-certificates.triggers b/debian/ca-certificates.triggers
> > > new file mode 100644
> > > index 0000000..14dec6e
> > > --- /dev/null
> > > +++ b/debian/ca-certificates.triggers
> > > @@ -0,0 +1,4 @@
> > > +interest-noawait update-ca-certificates
> > > +interest-noawait update-ca-certificates-fresh
> > 
> > As these are not supported by squeeze's dpkg, this can cause upgrade
> > problems (see below).
> > 
> > > +interest update-ca-certificates
> > > +interest update-ca-certificates-fresh
> > 
> > (OOC why the duplicates?)
> 
> They're not duplicated; it can handle both noawait and non-noawait
> triggers.

dpkg does not handle them as different trigger directives if there's
synchronous and asynchronous variants, they will just end up stomping
over each other. Given the current implementation, the last directive
wins, so I'd expect to see only the await variants in the dpkg
database. («cat /var/lib/dpkg/triggers/update-ca-certificates».)

In any case, regardless of this, semantics-wise I don't think it makes
much sense to have both of them present. I'll be fixing the
deb-triggers(5) man page to clarify this.

> > > diff --git a/debian/control b/debian/control
> > > index 5ef776e..8f84573 100644
> > > --- a/debian/control
> > > +++ b/debian/control
> > > @@ -13,9 +13,11 @@ Vcs-Browser: http://git.debian.org/?p=collab-maint/ca-certificates.git
> > >  
> > >  Package: ca-certificates
> > >  Architecture: all
> > > +Pre-Depends: dpkg (>= 1.16.1)
> > 
> > This only guarantees that this dpkg version will be configured before
> > installing this package, but not that the currently running dpkg will
> > be that one version, so the upgrade from squeeze can still fail due to
> > parser errors for the unknown triggers directive.
> 
> I've actually tested this, and it hasn't been a problem. I suppose the
> only way you could get it to be one is if you were manually using
> dpkg.

I was thinking about non-apt frontends, not just using dpkg directly.
The main issue here is that the metadata does not guarantee what you
want to do, and as such other non-apt frontends are not required to
prepare the upgrade transaction in the same way as apt (and I'm not
even sure it would be safe to expect that behaviour from apt, even if
it's what it's currently doing).

It'd probably be a good idea to discuss and try to come up with a way
to notify dpkg and/or frontends, that they might need to restart
themselves because a package requires one of its new features, so that
some of those can be deployed w/o having to wait a full release cycle.
I've added this to my TODO list for after wheezy.

> If that's really the case, then it basically means that no
> package in wheezy can use the noawait triggers at all.

Yes, that's always been the case for lots of dpkg features, that we
have to wait for a new release cycle before being able to use them. And
that's been the case for the noawait directives up to now, I've just
checked the lintian lab, and this is the only package using them.

Regards,
Guillem