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

Oh, ok.
 
> 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).

Ah, awesome. Ok, this wasn't clear at all to me from reading the
documentation. Let me try to rephrase to see if I've understood you
correctly:

interest triggername

just means that by default a dpkg-trigger will be considered to be a
synchronous trigger; if dpkg-trigger is called with --noawait, then it
does it asynchronously.

And "interest-noawait triggername" mean that the trigger will always
be asynchronous no matter how dpkg-trigger is called or the activate
trigger is listed.

Assuming I understand this properly now, I think I'll whip up a patch
to the git repository which explains this in more detail in the
manpage.

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

Ok. Do we still need a dependency for dpkg-trigger --no-await to work?
 
> 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. :)

Yeah. Another crazy option would be for dpkg to recognize that it was
upgrading itself, and rexec itself after upgrading itself if it has
more thins to do. But that's probably even more kinds of crazy.

 
Don Armstrong

-- 
in Just-
spring      when the world is mud-
luscious the little lame baloonman 

whistles       far       and wee 
 -- e.e. cummings "[in Just-]"

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