Re: Bug#671711: Assumptions when processing triggers (was [pkg-mono-group] Bug#671711: monodoc-browser: fails to upgrade) from 'testing'
On Fri, 08 Jun 2012, Guillem Jover wrote:
> Hmmm, so I had prepared a patch which basically checks if the package
> has its dependencies fulfilled before calling the postinst script with
> "triggered", and otherwise defers the trigger processing for later (but
> only as long as it is not running from inside the deferred trigproc run).
Since #680626 showed that this is a recurring problem, it would be nice
if we could do supplementary tests with the fixed dpkg to get a better
idea of the amount of problems that it creates.
Can you push your fix somewhere so that we can make tests?
> This fixes this specific case just fine (t-triggers-depends test
> case in dpkg/pkg-tests.git), but this in turn creates problems with
> packages with pending triggers depending on packages awaiting them,
> as it forces breaking trigger cycles, which is not really a nice
> upgrade path.
Because of the trigger cycles, you opted to change nothing. What about
enforcing some requirements which are less strong that the one desired?
(Probably only as a temporary stop-gap measure until we're able to
switch back to the full requirement)
The problematic fix is to ensure the same requirements for "postinst
triggered" as for "postinst configure". But we could enforce some
requirements that would probably solve the issues we saw without
Indeed, I believe it's relatively safe to run "postinst triggered"
- the dependencies are at least in status triggers-awaited
(this would go counter the logic that triggers-awaited package
are not really configured, but it would acknowledge the fact
that most packages should use "interest-noawait" instead)
- the dependency was already configured in a version (Config-Version
field) which satisfies the dependency
What do you think?
Raphaël Hertzog ◈ Debian Developer
Get the Debian Administrator's Handbook: