dist-upgrader needs backported dpkg/apt with triggers support

[Colin Watson]

Due to the transitional arrangements for dpkg-triggers, it is possible for the dpkg runs done by apt to do a dist upgrade to leave unprocessed triggers. (This is only true for the one apt run which installs the new dpkg.)

To ensure that triggers are properly run, and the user is not surprised by unexpectedly leftover trigger processing, the dist upgrader should run dpkg --configure --pending at some appropriate point late in the upgrade cycle, if it does not do so already (I haven't checked).

[Ian Jackson (ijackson)]

I agree that this behaviour looks unusual. The system is operating as designed.

It is difficult to do much better because of the way that apt invokes dpkg - in particular, the new dpkg doesn't get to run until the next run after it has been installed, and apt generally instructs dpkg only to process specific packages. We don't want to make dpkg process these transitional trigger states for all packages in an apparently unrelated run because that would be very unexpected for someone using dpkg from the command line (eg to fix a broken system).

So I don't propose to do anything about this in dpkg. However, we must make sure that the dist-upgrader definitely runs dpkg --configure --pending after the upgrade. I will add a task to this bug to reflect this and adjust the bug title etc. appropriately.

[Michael Vogt (mvo)]

I think making dpkg with triggers a pre-requist for the upgrade is a good idea here.

[Colin Watson (cjwatson)]

On Wed, Aug 22, 2007 at 02:39:53PM -0000, Ian Jackson wrote:
> It is difficult to do much better because of the way that apt invokes
> dpkg - in particular, the new dpkg doesn't get to run until the next run
> after it has been installed,

True, though in this case that is part of the same apt run (apt unpacks
and configures dpkg, then does everything else in a separate dpkg run
with the new dpkg).

> and apt generally instructs dpkg only to process specific packages.
> We don't want to make dpkg process these transitional trigger states
> for all packages in an apparently unrelated run because that would be
> very unexpected for someone using dpkg from the command line (eg to
> fix a broken system).
>
> So I don't propose to do anything about this in dpkg. However, we must
> make sure that the dist-upgrader definitely runs dpkg --configure
> --pending after the upgrade.

OK, this seems reasonable, but perhaps 'apt-get upgrade' should also do
this rather than just doing it in the dist-upgrader? After all apt
normally does try to configure anything that's unconfigured, IIRC; it
just doesn't notice that it needs to deal with pending triggers. I think
it would be reasonable for apt to check for pending triggers and deal
with them at the end of 'apt-get [dist-]upgrade'.

[Ian Jackson (ijackson)]

Colin Watson writes ("Re: [Bug 134000] Re: trigger processing remaining after upgrade"):
> OK, this seems reasonable, but perhaps 'apt-get upgrade' should also do
> this rather than just doing it in the dist-upgrader? After all apt
> normally does try to configure anything that's unconfigured, IIRC; it
> just doesn't notice that it needs to deal with pending triggers. I think
> it would be reasonable for apt to check for pending triggers and deal
> with them at the end of 'apt-get [dist-]upgrade'.

Yes.

Ian.

[Colin Watson (cjwatson)]

OK, let's have a task on apt for that, then.

[Michael Vogt (mvo)]

It turns out that update-manager need to use a libapt that understand about trigger-pending in "Status", otherwise the cleanup stage will fail. I retitle this bug accordingly.

[Michael Vogt (mvo)]

update-manager (1:0.72) gutsy; urgency=low

  * UpdateManager/Core/MetaRelease.py:
    - fix target filename for meta-release files so that
      correct I-M-S information is used
  * DistUpgrade/DistUpgrade.cfg:
    - use "release-upgrader-dpkg", "release-upgrader-apt" as
      update-pre-requists to fully support dpkg triggers (LP: #134000)
    - add mythubuntu-desktop to the valid metapackages
  * DistUpgrade/DistUpgradeControler.py:
    - fix pre-requists fetching, do not run the resolver as the udebss
      are not installable on a regular system
    - generate more log information to make diagnosing problems easier
    - setup RELEASE_UPGRADE_IN_PROGRESS environemnt
    - use custom invoke-rc.d during the upgrade so that failures to
      restart a daemon are not fatal
  * DistUpgrade/prerequists-sources.list:
    - point to the archive for the pre-requists now

 -- Michael Vogt <email address hidden> Fri, 07 Sep 2007 23:29:40 +0200

[FlagMan (flagman)]

Please correct me if I am wrong, but bug #146943 seems to
suggests that these fixes are not enough.

Over there, fx5 did the following analysis:

python-apt is packaged with python-central.
python-central use dpkg-query to read the package-fields (like Python-Version).
dpkg-query seems to fail, because it is the old (feisty-) version that does know about triggers.
There is a trigger-status for libc6.