# not a reason to block -13 from testing found 495359 5.10.0-11.1 thanks On Sat, Aug 16, 2008 at 05:43:23PM +0200, Henning Glawe wrote: > Subject: perl is in an unusable state during etch->lenny dist-upgrade and > breaks the upgrade process > Package: perl > Version: 5.10.0-13 > Severity: critical > Justification: breaks unrelated software
> 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 /u > 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 > iU perl 5.10.0-11.1 > ii perl-base 5.8.8-7etch3 > iU perl-modules 5.10.0-11.1 Thanks for the report. First, what happens here is that the 'old-prerm upgrade' invocation of gs-common invokes /usr/bin/defoma-app, which needs File::Copy from perl-modules. The new perl-modules and perl packages have been unpacked but not configured yet, so their dependencies are not guaranteed to be satisfied (and indeed, the critical perl -> perl-base dependency isn't.) Quoting Brendan O'Dea in #479711, in the "Locale::Gettext problem" context: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479711#120 > One issue which should be highlighted is that no such guarantees are > made *during* the upgrade process. In fact Debian policy is pretty > explicit as to what is valid for maintainer scripts to invoke: either > the package providing the binary must be flagged as "Essential" (in > which case there are additional requirements placed on the package > such that it is functional even when not configured) or a > Pre-Dependency must be declared (ensuring that dpkg with not only > unpack, but will configure said dependency package before attempting > to configure the dependant). (The perl-base package is the only Essential:yes one built from the perl source.) That said, I can't find this explicit explanation in the policy myself. Section 7.2 looks like the place, but these come closest: http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps The Depends field should also be used if the postinst, prerm or postrm scripts require the package to be present in order to run. [...] Pre-Depends should be used sparingly, preferably only by packages whose premature upgrade or installation would hamper the ability of the system to continue with any upgrade that might be in progress. Pre-Depends are also required if the preinst script depends on the named package. It is best to avoid this situation if possible. Brendan (and others), help would be welcome. Even if this is deemed to be a policy violation by the gs-common package, I suspect it's not the only one, and finding them all is non-trivial. I'll have to think a bit about any possibilities of solving this with Pre-Dependencies. I also wonder if using Conflicts: perl-base (<< 5.10.0) or something like that might work. Merging perl-base, perl and perl-modules seems like a very intrusive change at this stage of the release cycle. > I have a backup of the etch system, so in case you want me to check for > something specific i can reproduce this in a chroot. Please send the result of 'dpkg -l > list' (it chops off long columns if outputting to the terminal) in the initial state with Etch installed, so I can set up a similar chroot and try to reproduce it. -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
