Control: tags -1 + moreinfo
Hi *,
2014-11-12 13:51 David Kalnischkies:
On Wed, Nov 12, 2014 at 10:34:09AM +0100, Axel Beckert wrote:
Cesare Leonardi wrote:
> On three different PCs (Debian unstable, i386, 32 bit) i'm frequently
> encountering a problem, where aptitude (curses interface), without any
> error to the user, leaves some package in an incomplete state.
[...]
> I'm not sure, but i believe that this problem appeared after one of the
> recent dpkg upgrade.
It's first got reported a few weeks ago. But since this is not the
first report this week -- there was another one yesterday -- I suspect
that some broken packages have been uploaded recently to Debian which
break some commonly installed triggers.
The underlying problem is "breakage" in the interaction of dpkg and apt
in terms of triggers, see #766758.
The issue being that some triggers will stay pending/packages stay
awaiting after libapt is done calling dpkg. Following calls of apt tools
should report them as "half-installed" or similar such (depending on how
detailed you want to be. See also dpkg -C for a complete list). Usually,
as apt tools prefer to go from one good state to another the solution
should include finishing the installation of them (meaning, libapt will
call --configure on them). This might or might not get you into
a complete done state as some things are trigger-happy – in other words:
The completion of one trigger could trigger another trigger.
I haven't really decided (mostly thanks to time issues) yet how to tackle
this giant ball of pain and on top of that how to sell it to the Release
Team if I would find a fix from the apt side. As said in the mentioned
bugreport, that wouldn't help in any way with wheezy-upgrades though.
Still, we have no report against apt about this, but I am seeing
multiple for aptitude, so I suspect there is something more to it from
the aptitude side in how it deals with triggers, so I wouldn't advice to
just reassign them to apt/dpkg now without further inspection.
(it could just be that apt isn't really too talkative about
half-installed packages if encounter. It will just fix it up and mention
it as a single line in the usual what-we-will-do-summary stats and as
triggers are usually not too important for the operation of the system
nobody realizes that something is fishy, but I want you to check first)
I remember seeing this when happened in ~Oct 2014, but I haven't seen
any occurrence since then.
In the dpkg commit fixing #766758, it says:
This is a mostly conformant workaround for frontends like apt that do
not correctly call «dpkg --configure -a» or «dpkg --triggers-only -a»
after their normal runs, and leave packages in triggers-pending and
triggers-awaited states.
I am not sure if the front-ends are suppossed to be modified to call
dpkg correctly because this "conformant workaround" will be removed, or
what's the situation. Can you please clarify, if you know the reply
right away? If you have to dig no problem, I will do it.
Guillém (from dpkg) told me that it had been fixed in apt, and aptitude
only calls in one section "dpkg --configure -a", not individually "dpkg
--configure $pkg", so I think that it relies on apt for this task and so
there's nothing to do from aptitude's side.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
