Bug#503712: etch->lenny upgrade left the system in broken state
On Mon, Oct 27, 2008 at 07:33:57PM +0100, Giovanni Rapagnani wrote:
> Package: upgrade-reports
> 'aptitude install -f' is not able to fix the problem and seems to block
> when trying to remove the gs-common package. See attachment file
> 3_dist-upgrade_all_messages, do a search with pattern 'Removing
> gs-common'.
> Removing gs-common ...
> Can't locate File/Copy.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/bin/defoma-app line 7.
> BEGIN failed--compilation aborted at /usr/bin/defoma-app line 7.
> dpkg: error processing gs-common (--remove):
> subprocess pre-removal script returned error exit status 2
> Errors were encountered while processing:
> gs-common
> E: Sub-process /usr/bin/dpkg returned an error code (1)
This is pretty much #495703, the prerm script of the etch gs-common
package breaks if the perl packages are being upgraded and just
part of them are unpacked.
It was thought fixed by making the lenny gs-common prerm script survive
'failed-upgrade', but I see gs-common can end up removed, not upgraded,
when doing the dist-upgrade.
This presumably happens because the lenny ghostscript conflicts with
gs-common (<< 8.62), and as gs-common was originally pulled in as an
automatic dependency, aptitude thinks it's best to just remove it.
Suggest cloning/reassigning to ghostscript. Making the lenny ghostscript
depend on the lenny gs-common might fix this, except that would create
a circular dependency. Maybe somebody can come up with something better.
Starting with a minimal Etch chroot:
# apt-get -y install gs-common devscripts wget
# sed -i s/etch/lenny/ /etc/apt/sources.list
# apt-get update
# dget ghostscript
# dget perl-modules
# dpkg --auto-deconfigure --unpack perl-modules_5.10.0-16_all.deb ghostscript_8.62.dfsg.1-3.1_amd64.deb
--
Niko Tyni ntyni@debian.org
Reply to: