On Wed, 24 Dec 2008, Asheesh Laroia wrote:
On Wed, 24 Dec 2008, Asheesh Laroia wrote:
Right now, I'm going to try testing if listing gs-common in
/etc/apt/apt.conf.d/01autoremove helps.
I can't come up with a recipe for reproducing this that uses apt (apt-get OR
aptitude), not just dpkg --unpack. So I'm at a roadbloack; I can't do the
experiment because I don't have a control.
I just created a Xen guest for testing this to ensure a good simulation
(rather than a chroot). I created a fresh Etch install on amd64, used
tasksel to enable Desktop, Web server, and SQL server, and waited for them
to successfully finish.
Then I did:
* (Switch sources.list to lenny)
* aptitude install apt aptitude dpkg
* aptitude install xserver-xorg-video-all
So far, so good, just like the original message in the bug.
Then I did:
$ aptitude dist-upgrade
"Unfortunately" this downloaded ca. 1000 packages and seemed to work fine
for me. One of the first things that happens is gs-common gets removed.
Because this happens before perl-modules is changed, there is no chance to
tickle the broken prerm script from gs-common.
Therefore I still see no way to test for this issue with apt(itude) which
would test the apt-related fix. I don't know of a way to influence the
ordering to encourage apt to partially upgrade perl-modules first, which
is the problematic scenario.
SCENARIO 1
APT removes gs-common in the dist-upgrade. This can cause a bad race
between the broken maintainer script of gs-common and perl-modules, if
perl-modules is partially upgraded at the time that gs-common gets
removed.
SCENARIO 2
I can verify that adding gs-common to /etc/apt/apt.conf.d/01autoremove
causes APT to download one extra file:
Get:1 http://mirrors.acm.jhu.edu lenny/main gs-common 8.62.dfsg.1-3.1 [28.4kB]
In this scenario, gs-common is upgraded rather than removed, removing the
possibility of this race, because the broken etch gs-common maintainer
prerm script is never run.
MY CONCLUSION
Given these two scenarios, I believe we are best-off by modifying
aptitude's 01autoremove to avoid autoremoving gs-common.
I have attached a patch to *apt* from lenny (with NMU-style changelog, but
it's just an explanation of what I suggest; I don't plan to personally
upload that modified package yet!).
I believe that adding the change this change would adequately fix the
issue.
ALTERNATIVE
As suggested, we could hack the ghostscript.config script to forcefully
remove the prerm of gs-common. I'll email this bug with a suggested NMU
that implements that strategy.
-- Asheesh.
--
You have a reputation for being thoroughly reliable and trustworthy.
A pity that it's totally undeserved.
diff -urN apt-0.7.19/debian/apt.conf.autoremove
apt-0.7.20/debian/apt.conf.autoremove
--- apt-0.7.19/debian/apt.conf.autoremove 2008-06-09 17:10:09.000000000
-0400
+++ apt-0.7.20/debian/apt.conf.autoremove 2008-12-25 19:20:00.000000000
-0500
@@ -4,5 +4,6 @@
{
"^linux-image.*";
"^linux-restricted-modules.*";
+ "^gs-common$";
};
};
diff -urN apt-0.7.19/debian/changelog apt-0.7.20/debian/changelog
--- apt-0.7.19/debian/changelog 2008-11-24 04:35:21.000000000 -0500
+++ apt-0.7.20/debian/changelog 2008-12-25 20:04:41.000000000 -0500
@@ -1,3 +1,12 @@
+apt (0.7.19+nmu1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * apt.conf.autoremove: Add gs-common to list of packages not to be
+ autoremoved. This works around a bad bug in the etch gs-common prerm
+ where it fails to execute while perl is partially unpacked in an upgrade.
+
+ -- Asheesh Laroia <[email protected]> Thu, 25 Dec 2008 19:31:28 -0500
+
apt (0.7.19) unstable; urgency=low
[ Eugene V. Lyubimkin ]
