[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#503712: etch->lenny upgrade left the system in broken state



reassign 503712 ghostscript 8.62.dfsg.1-3.1
severity 503712 serious
thanks

On Wed, Oct 29, 2008 at 10:21:47PM +0200, Niko Tyni wrote:
> On Mon, Oct 27, 2008 at 07:33:57PM +0100, Giovanni Rapagnani wrote:

> > 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.

> 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.

Reassigning and raising severity, hope that's the right thing to do.
To recap, this is one way to reproduce it:

> 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 

On Thu, Oct 30, 2008 at 12:52:28PM +0100, Giovanni Rapagnani wrote:
> On 30/10/08 10:33, Niko Tyni wrote:
>> Upgrading gs-common first should work around the problem.
>> Not sure what's the best way to recover the upgrade;
>> maybe 'aptitude install gs-common' is enough.
>
> Yes, it worked. 'aptitude install gs-common' and then 'aptitude 
> dist-upgrade' upgraded the system.
>
> Is this something that needs documentation in the release-notes ?

I think it would be much better to fix the upgrade path if possible.
-- 
Niko Tyni   ntyni@debian.org



Reply to: