Moin,
seems like in the dist-upgrade from etch to lenny is one very annoying (and
old, AFAIR I hit it already in woody->sarge and sarge->etch) problem: perl is
in an unusable state during the upgrade and causes maintainer scripts to
fail.

I was following way:
- update from etch and etch-security
- change sources.list (lenny instead of etch)
- update-procedure:
apt-get update
aptitude install aptitude
aptitude dist-upgrade

after the system working for a while, maintainer scripts started to fail and
aptitude exited.
the maintainer-script errors were perl-related: the interpreter could not
find modules (all from perl-base) in @INC.
further investigation showed that perl-base was still installed in the
etch-version, while perl itself was from lenny (and of course, the lenny
version was not finding its own versioned modules from perl-base).

i worked around this by installing perl-base from lenny using dpkg.
which also failed due to the dependency loop between perl and perl-base.

dpkg --configure perl perl-base perl-modules

then put the perl back to a usable state (as dependency loops are fine, as
long as dpkg configures all parts of the loop in one call).

Why not merge the three packages into one? the only package saving mirror
space due to its 'arch:all'iness is perl-modules, which would add 3.2M per
architecture to the mirror network, but is a constant source of troubles with
perl transitions?

Now the dist-upgrade is running on, I'll keep you updated on the progress

--
c u
henning


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Wed, Aug 13, 2008 at 03:40:15PM +0200, Henning Glawe wrote:

> seems like in the dist-upgrade from etch to lenny is one very annoying (and
> old, AFAIR I hit it already in woody->sarge and sarge->etch) problem: perl is
> in an unusable state during the upgrade and causes maintainer scripts to
> fail.

> after the system working for a while, maintainer scripts started to fail and
> aptitude exited.
> the maintainer-script errors were perl-related: the interpreter could not
> find modules (all from perl-base) in @INC.
> further investigation showed that perl-base was still installed in the
> etch-version, while perl itself was from lenny (and of course, the lenny
> version was not finding its own versioned modules from perl-base).

Thanks for the report. Do you have any logs left? At least
/var/log/dpkg.log and /var/log/aptitude.log would be interesting. Please
file a bug against the perl package with those, and preferably some of
the error messages you got of course.

I haven't seen this kind of breakage myself in test upgrades, and the
issues reported so far have been related to the "Locale::Gettext problem"
(#488300 et al.)

BTW, I think there must be something wrong with your description:
/usr/bin/perl is in perl-base, and it certainly should find the modules
in perl-base itself...
--
Niko Tyni ntyni@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Wed, Aug 13, 2008 at 09:12:03PM +0300, Niko Tyni wrote:
> On Wed, Aug 13, 2008 at 03:40:15PM +0200, Henning Glawe wrote:
> > the maintainer-script errors were perl-related: the interpreter could not
> > find modules (all from perl-base) in @INC.
> > further investigation showed that perl-base was still installed in the
> > etch-version, while perl itself was from lenny (and of course, the lenny
> > version was not finding its own versioned modules from perl-base).
>
> Thanks for the report. Do you have any logs left? At least
> /var/log/dpkg.log and /var/log/aptitude.log would be interesting. Please
> file a bug against the perl package with those, and preferably some of
> the error messages you got of course.

problem is that I did this on the console without any logging facilities...
luckyly, I have a system backup from yesterday; I could put this into a
chroot and repeat the whole procedure in a chroot environmen (packages are
already here in my apt-proxy).
I can use 'screen' with logging, so.


> I haven't seen this kind of breakage myself in test upgrades, and the
> issues reported so far have been related to the "Locale::Gettext problem"
> (#488300 et al.)

I did not see Locale::Gettext / missing locales here, because I also know of
this issue and used LC_ALL=C in the rootshell used to do the dist-upgrade
(normally, I use a "en_US.UTF-8" locale).


> BTW, I think there must be something wrong with your description:
> /usr/bin/perl is in perl-base, and it certainly should find the modules
> in perl-base itself...

you are right... sorry for the sloppy research :S... think it must have been
the perl-base<->perl-modules version mismatch. I'll try to reproduce this
immediately.

--
c u
henning


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Henning Glawe schreef:
> Moin,
> seems like in the dist-upgrade from etch to lenny is one very annoying
> (and old, AFAIR I hit it already in woody->sarge and sarge->etch)
> problem: perl is in an unusable state during the upgrade and causes
> maintainer scripts to fail.
>
> I was following way:
> - update from etch and etch-security
> - change sources.list (lenny instead of etch)
> - update-procedure:
> apt-get update
> aptitude install aptitude
> aptitude dist-upgrade
>
> after the system working for a while, maintainer scripts started to fail
> and aptitude exited.
> the maintainer-script errors were perl-related: the interpreter could not
> find modules (all from perl-base) in @INC.
> further investigation showed that perl-base was still installed in the
> etch-version, while perl itself was from lenny (and of course, the lenny
> version was not finding its own versioned modules from perl-base).
>
> i worked around this by installing perl-base from lenny using dpkg.
> which also failed due to the dependency loop between perl and perl-base.
>
> dpkg --configure perl perl-base perl-modules

FWIW, I've seen something similar, although I think I had the whole new
perl (perl, perl-base and perl-modules) unpacked at least. The proplem
seemed to be that the @INC line still had entries only from 5.8 while 5.10
was unpacked. I hadn't any time to research the problem in more detail, so
this message will not transcend the level of a ``me too!'-message

grts Tim


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Henning Glawe wrote:

i worked around this by installing perl-base from lenny using dpkg.
which also failed due to the dependency loop between perl and perl-base.

dpkg --configure perl perl-base perl-modules

then put the perl back to a usable state (as dependency loops are fine, as
long as dpkg configures all parts of the loop in one call).

I have had the same problem, but I didn't get any dependency loop
issues. On one system I think I had to start upgrading other perl
modules manually too.


On one system I run "apt-get upgrade" first before the "apt-get
dist-upgrade". This system had no problems. Normally I just do an
"apt-get dist-upgrade".


Unfortunately I was in a hurry to get the systems up and running (my
time is rather constrained) so didn't investigate in detail required to
file a quality bug report. I should still have the log files available
however.


Brian May


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Wed, Aug 13, 2008 at 09:12:03PM +0300, Niko Tyni wrote:
> BTW, I think there must be something wrong with your description:
> /usr/bin/perl is in perl-base, and it certainly should find the modules
> in perl-base itself...

ok, did the update starting from my system-backup; error-messages in the
maintainer scripts (sorry for the overlong lines, but I wanted to paste them
here intact):

---------------------- begin error messages ---------------------------
Removing gs-common ...
Can't locate File/Copy.pm in @INC (@INC contains: /home/glaweh/bin/perl5 /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
Can't locate File/Find.pm in @INC (@INC contains: /home/glaweh/bin/perl5 /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/debsums line 10. BEGIN failed--compilation aborted at /usr/bin/debsums line 10. E: Problem executing scripts DPkg::Post-Invoke 'if [ -x /usr/bin/debsums ]; then /usr/bin/debsums --generate=nocheck -sp /var/cache/apt/archives; fi'
E: Sub-process returned an error code
E: Sub-process /usr/bin/dpkg returned an error code (1)
---------------------- end error messages ---------------------------


---------------------- begin perl package state -----------------------
n033:/# dpkg -l perl perl-base perl-modules
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-============================-============================-================================================== ======================
iU perl 5.10.0-11.1 Larry Wall's Practical Extraction and Report Language
ii perl-base 5.8.8-7etch3 The Pathologically Eclectic Rubbish Lister
iU perl-modules 5.10.0-11.1 Core Perl modules
---------------------- end perl package state -----------------------

--
c u
henning


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hi,

On Sat, Aug 16, 2008 at 02:16:58PM +0200, Henning Glawe wrote:
> On Wed, Aug 13, 2008 at 09:12:03PM +0300, Niko Tyni wrote:
> > BTW, I think there must be something wrong with your description:
> > /usr/bin/perl is in perl-base, and it certainly should find the modules
> > in perl-base itself...
>
> ok, did the update starting from my system-backup; error-messages in the
> maintainer scripts (sorry for the overlong lines, but I wanted to paste them
> here intact):
...
> ---------------------- begin perl package state -----------------------
Can you post "dpkg -l perl perl-base perl-modules defoma debsums" before
and after the upgrade.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Henning Glawe wrote:

you are right... sorry for the sloppy research :S... think it must have been
the perl-base<->perl-modules version mismatch. I'll try to reproduce this
immediately.


Yes, I think this is the issue.

I wrote an ugly script to reproduce from a almost pristine etch chroot[1]

#/bin/sh -ex
dpkg -l perl perl-base perl-modules
apt-get install --yes debsums
sed -i s/etch/lenny/ /etc/apt/sources.list
apt-get update
apt-get install --yes -d perl perl-modules tzdata
dpkg -i /var/cache/apt/archives/tzdata_2008e-2_all.deb
dpkg -i /var/cache/apt/archives/libc6_2.7-13_amd64.deb
dpkg --unpack /var/cache/apt/archives/perl_5.10.0-11.1_amd64.deb
dpkg --unpack /var/cache/apt/archives/perl-modules_5.10.0-11.1_all.deb
dpkg -l perl perl-base perl-modules
debsums


Results:

+ dpkg -l perl perl-base perl-modules

Desired=Unknown/Install/Remove/Purge/Hold

| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed

|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)

||/ Name Version Description

+++-==============================================-==============================================-================================================== ================================================== ========

ii perl 5.8.8-7etch3 Larry Wall's Practical Extraction and Report Language

ii perl-base 5.8.8-7etch3 The Pathologically Eclectic Rubbish Lister

ii perl-modules 5.8.8-7etch3 Core Perl modules

...

+ dpkg --unpack /var/cache/apt/archives/perl_5.10.0-11.1_amd64.deb

(Reading database ... 12309 files and directories currently installed.)

Preparing to replace perl 5.8.8-7etch3 (using .../perl_5.10.0-11.1_amd64.deb) ...

Unpacking replacement perl ...

+ dpkg --unpack /var/cache/apt/archives/perl-modules_5.10.0-11.1_all.deb

(Reading database ... 11957 files and directories currently installed.)

Preparing to replace perl-modules 5.8.8-7etch3 (using .../perl-modules_5.10.0-11.1_all.deb) ...

Unpacking replacement perl-modules ...

+ dpkg -l perl perl-base perl-modules

Desired=Unknown/Install/Remove/Purge/Hold

| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed

|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)

||/ Name Version Description

+++-==============================================-==============================================-================================================== ================================================== ========

iU perl 5.10.0-11.1 Larry Wall's Practical Extraction and Report Language

ii perl-base 5.8.8-7etch3 The Pathologically Eclectic Rubbish Lister

iU perl-modules 5.10.0-11.1 Core Perl modules

+ debsums

Can't locate File/Find.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/debsums line 10.

BEGIN failed--compilation aborted at /usr/bin/debsums line 10.


This looks identical to the failure mode.

Note it isn't possible to configure perl and perl-modules because the
required version of
perl-base has not been installed - again this is similar to what happens
in the failing upgrade

process.

Unfortunately so far when I try to reproduce the problem using "apt-get
dist-upgrade" from the same
chroot it works fine. I would guess the issue is that postrm and
DPkg::Post-Invoke scripts are using perl

when it is in this broken state.

Notes:
[1] only difference is build-essentials and fakeroot installed and
installation of recommends turned

off by default; I doubt these had any effect.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org