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

[Don Armstrong]

On Fri, 30 Nov 2012, Guillem Jover wrote:
> 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.

I'm not sure I follow you here; allowing for both of them means that
the triggering package can define whether the triggered feature is
crucial, or not essential to its function. Doing it the other way
around means that only the triggered package can define whether the
feature is crucial or not essential.
 
> 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).

I'll test it again with aptitude and see if it also works. If it
doesn't, the documentation in deb-triggers should really be updated,
as it currently suggests the exact solution I implemented.

> 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.

That should actually be pretty easy for the frontends just to handle.
If a package pre-depends on dpkg or some other essential package
required for the upgrade, it should do those upgrades first, then do
the rest of them. dpkg doesn't really need to do anything.

> > 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.

Ok. However, noawait is the only way to solve this particular bug
without doing nasty things in the preinst script because otherwise the
trigger gets run before the new version of ca-certificates-java is
configured.


Don Armstrong

-- 
You could say to the Universe this is not /fair/. And the Universe
would say: Oh it isn't? Sorry.
 -- Terry Pratchett _Soul Music_ p357

http://www.donarmstrong.com              http://rzlab.ucr.edu