(sry about leaving you guys hanging… I am not exactly blessed with free
time at the moment and this stuff requires the exact opposite… anyway,
more a problem description/comment than a solution. Far from the later…)
On Sun, Jan 25, 2015 at 12:45:10AM +0000, Simon McVittie wrote:
> Is the fix for https://bugs.debian.org/769609 expected to fix this
> particular issue, or am I misreading it?
No. Its not fixing any issue at the moment. It will be if dpkg/stretch
drops its compatibility "run all runnable pending triggers" code, but
that is (not) going to effect you in the jessie -> stretch upgrade; not
now nor would it help as this trigger is not runnable (given that dpkg
tries, but ultimatively fails to do so) and all this bug is supposed to
prevent is that triggers which should have been run are not.
So whats the problem? Lets pretend this universe (which is a simplified
realworld one):
Package: systemd-sysv
Depends: systemd
Package: systemd
Postinst: trigger dbus-trig
Package: dbus
Depends: libdbus-1-3
Trigger: interest-await dbus-trig
Package: libdbus-1-3
Now, for simplicity lets just assume all of these packages are already
installed and we are going to install them again. Lets further assume
we pick libdbus-1-3 to be unpacked first and then we deal with the rest,
like this:
dpkg --unpack libdbus-1-3*.deb
dpkg --install systemd*.deb
dpkg --configure libdbus-1-3
So, what you will see is that the second dpkg call will fail because
systemd will end up in 'iW' on dbus which itself can't leave 'it' as it
depends on libdbus-1-3 which is just unpacked ('iU').
This never happened in the past as dpkg would just run the dbus trigger
anyway (not ideal, right?). This new style assumes on the other hand that
a dpkg-frontend like apt is making stuff up on the go rather than
planning out what to do once as for a frontend like apt the need to run
the dbus trigger comes out of no-where and derails the entire plan.
Now the universe constructed above is totally made up in that it is so
simple. In this simple scenario apt doesn't call dpkg in that way. Why
it runs dpkg in this way and insists on it I haven't checked "thanks" to
time issues, but given that this is the only trigger I know of there it
happens in real life and it isn't even limited to wheezy-upgrades (as
I got this on a sid system (only updated once in a blue moon through)
the other day) I presume its a very special snowflake thing going on
around pseudo-essentials, pre-depends and conflicts which apt is trying
to eagerly to avoid and instead steps on this trigger trap (SCNR).
> Or if dropping it down to interest-noawait would help, that isn't
> really semantically correct, but it's probably acceptable in practice?
Its not helping the general case of course, but -noawait triggers can't
run in to this problem as nothing can end up in 'iW' with them. So if
you think this is acceptable, I think it might be better than the
alternatives like ripping this out of dpkg again or busy-waiting for me
to figure something out (especially as I doubt that it will be pretty or
even simple if at all solveable for wheezy-upgrades given we only have
apt/wheezy for it…).
Best regards
David Kalnischkies
P.S.: apt isn't recovering in this situation as it ignores 'iW' states,
while it should probably just "half-ignore" it by trying to get the
system in a state in which the package could be configured, but never
explicitely requesting the trigger processing, but the commit making it
ignore it is years old and as usual: changes to the install-order scare
the shit out of me, especially five minutes before release.
Attachment:
signature.asc
Description: Digital signature