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

[Guillem Jover]

On Fri, 2012-11-30 at 11:24:48 -0800, Don Armstrong wrote:
> 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.

This is already supported, and now having rechecked the patch in more
detail and having paid attention :), you are already making use of it
by calling dpkg-trigger with --no-await, which activates a trigger w/o
marking the activating package as needing to await processing.

You have to think about the interest* directives as default behaviour,
so if the directive is synchronous, you can still activate it
asynchronously (with dpkg-trigger --noawait). If the interested package
marks it as noawait then it means it's really never needed for
triggering packages to await processing; an example of this latter case
could be man page cache regeneration.

Those default directives are also needed so that implicit triggering,
like the ones activated via path changes by dpkg itself during
unpack/remove/etc, can behave in a way or another, but there needs
to be only one, two directives does not make sense, which one would
apply then?

So, it really looks like these packages were behaving like if they only
had «interest foo» (due to the stomping I mentioned before) and the
trigger was asynchronous anyway due to the dpkg-trigger call, so you
don't really need to use interest-noawait support nor the dpkg
Pre-Depends anyway, and the possible upgrade issues just disappear.

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

That's one of the solutions that had crossed my mind too, but it might
be too restritive in how frontends might need to prepare transactions,
so it might be too heavy handed. The only problem here is just dpkg
(perhaps the frontends itself too, but nothing else really), as the
running process that gets out of sync with its own database, but asking
frontends to hardcode a special case for the dpkg package might not be
liked, and instead a metadata-based solution might be preferred, that's
why I mentioned that this would need discussion. :)

Thanks,
Guillem