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 14:44:03 -0800, Don Armstrong wrote:
> On Fri, 30 Nov 2012, Guillem Jover wrote:
> > 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.

Correct.

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

Cool, that'd be wonderful, I'll happily queue it for 1.17.x. If you
are going to mention dpkg-trigger (an explicit trigger) it would be
nice to also mention implicit triggers too. And it probably also makes
sense to avoid using the “(a)synchronous” language when talking about
triggers as that is not used in any other place when talking about
them.

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

Nope, «dpkg-trigger --no-await» is supported since dpkg 1.14.17, the
version that introduced triggers.

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

Yes, this also crossed my mind :). In principle it should not require
that much code jugling, but I'd have to review the code paths to make
sure how much state might need to be preserved (like status-fds) or
flushed to disk if it's still not there, etc. It still might be too
heavy handed, because a package Pre-Depending on dpkg might need
features provided by one of the other tools (like dpkg-query), which
would not require the dpkg process to restart, and we might still
want to have control over when this happens.

Thanks,
Guillem