On Sat, Aug 16, 2008 at 09:21:54PM +0300, Niko Tyni wrote: > 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.)
well, there are some other cases related to debsums in other maintainer scripts (in one of my experiments, i simply "disabled" the error in gs-common by letting the prerm in /var/lib/dpkg/config directly exit with exitcode 0. > 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. well, then how to solve the problems of maintainer scripts using the more complex debian helpers like defoma/debsums? make each package pre-depend on the corresponding package and them in turn on perl? this is AFAIK impossible and clutters the archive by big amounts... so one idea would be to change the maintainer script interface of defoma/debsums/whatever to only use modules contained in perl-base. but then, in turn: do we now need release notes to manually update half of the system before running aptitude dist-upgrade? i think this is most easily solved with proper dependencies of the perl packages, maybe by introducing a conflicts with a too-old perl-base package. > 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. and AFAIK this has to be solved before the lenny release. > 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. Pre-Dependency together with conflicts worked a few years ago when updating a a huge amount of machines from woody to sarge; for this, I prepared locally patched perl packages with the following changes: * perl-base: - Conflicts: perl (<< 5.8.0-1), perl-modules (<< 5.8.0-1) * perl-modules: - unchanged * perl: - moved from Depends: to Pre-Depends: perl-base (= 5.8.4-5.1) this combination forced apt to update the perl packages in the right order, meaning the order to keep all three packages consistent which fixed similar problems at that time. p.s.: this change was rejected at that time with the argument you quoted from Brendan O'Dea, i.e. that it is basically the mainainer scripts' fault and not perls. I know that a pre-depends is a quite strong measure, but in this case it is AFAIK justified... > Merging perl-base, perl and perl-modules seems like a very intrusive > change at this stage of the release cycle. yes, and also quite improbable to be accepted by the embedded crowd... difficulty is, that this problem is seen very rarely during the normal testing cycle and it can be observed most often when it is too late: when people are already upgrading from old-/stable to testing/stable. > 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. should be attached to this mail :) you may have problems finding some of the packages, i have backported and packaged from scratch a lot of stuff on my own... -- c u henning
ruprecht-backup-20080813-2.dpkg-l.gz
Description: Binary data
