As far as I've been able to determine, there's no way to resolve this by
means of even something as strenuous as Pre-Depends, without causing
other worse problems (e.g. Pre-Depends loops; perl-base and perl-modules
have to be in sync, not merely in order). As documented in policy, a
prerm may only assume the following:
The package whose prerm is being called will be at least "Half-
Installed". All package dependencies will at least be "Half-Installed"
and will have previously been configured and not removed. If there was
no error, all dependencies will at least be unpacked, but these actions
may be called in various error states where dependencies are only "Half-
Installed" due to a partial upgrade.
The libwmf0.2-7 situation is exactly what policy is warning about; the
dependencies are only unpacked and not configured.
The strategy we're adopting when we find such upgrade bugs is to correct
the package to conform to policy instead, to avoid prerms requiring
configured dependencies; there is really no other workable solution as
far as I've been able to determine, although I appreciate that it does
initially seem as though it should be possible to fix it in perl (I've
been down this road already). In some cases this can be achieved by
causing them to require only Essential packages, which are required to
always behave as if they were configured after they've been configured
once; for instance, a Perl script can do this by relying only on those
modules in perl-base.
In the case of libwmf0.2-7, however, defoma has mercifully been
deprecated and is on its way out, so the fix is essentially just to stop
using it. This had been done in Debian by the time I saw this upgrade
failure, so I merged that change into precise. There was one last tweak
required: when dpkg is upgrading a package and the prerm from the old
version fails, it will fall back to trying the new version; so, in the
knowledge that the old prerm was likely to fail, I added a no-op prerm
to the new version of libwmf0.2-7 so that dpkg would fall back to that
and thus succeed. I've tested that this is sufficient to get past that
upgrade failure. This was bug 904901, so I'll leave that be and
consider only debsums in this bug from this point onward.
The debsums failure is new to me; but in that case, it's being run out
of band to some extent, and I think it would therefore be prudent of it
to rely only on packages in the Essential set. We did something similar
with doc-base. perl-base and perl-modules could then Conflict with
versions of debsums before that fix.
** Package changed: perl (Ubuntu) => debsums (Ubuntu)
** Changed in: debsums (Ubuntu)
Importance: Undecided => Critical
** Changed in: debsums (Ubuntu)
Status: New => Triaged
** Changed in: debsums (Ubuntu)
Importance: Critical => High
** Tags added: dist-upgrade lucid2precise rls-mgr-p-tracking
** Changed in: debsums (Ubuntu)
Milestone: None => ubuntu-12.04-beta-1
** Changed in: debsums (Ubuntu)
Assignee: (unassigned) => Canonical Foundations Team
(canonical-foundations)
** Also affects: debsums (Ubuntu Precise)
Importance: High
Assignee: Canonical Foundations Team (canonical-foundations)
Status: Triaged
** Summary changed:
- perl-modules lucid->precise upgrade failure
+ perl-modules lucid->precise upgrade failure: debsums needs to restrict itself
to Essential dependencies
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/901741
Title:
perl-modules lucid->precise upgrade failure: debsums needs to restrict
itself to Essential dependencies
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debsums/+bug/901741/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
