(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.
signature.asc
Description: Digital signature