On Mon, Aug 18, 2008 at 02:52:56PM +0200, Henning Glawe wrote: > On Sat, Aug 16, 2008 at 09:21:54PM +0300, Niko Tyni wrote: > > 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.
Ah, I think I grok it now. Section 6.6 states that 'old-prerm upgrade' is run at the unpack phase, which makes it equivalent to the preinst case: non-essential dependencies must be Pre-Depended on. http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase Actually, even an unversioned Pre-Dependency may not be enough when upgrading. Section 7.2: http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps When a package declaring a pre-dependency is about to be unpacked the pre-dependency can be satisfied if the depended-on package is either fully configured, or even if the depended-on package(s) are only unpacked or half-configured, provided that they have been configured correctly at some point in the past (and not removed or partially removed since). In this case, both the previously-configured and currently unpacked or half-configured versions must satisfy any version clause in the Pre-Depends field. So even an unversioned 'Pre-Depends: perl-modules' wouldn't be enough... > 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? My interpretation is that 'prerm upgrade' may only rely on essential packages or carefully versioned pre-dependencies being functional, Just to be sure: this does not apply to the configure stage, the postinst script can rely on the dependencies being fully configured (module circular dependencies). > 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? There's still a way out when 'old-prerm upgrade' fails: dpkg then calls 'new-prerm failed-upgrade' that can fix the situation. > 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. For reference, this was last discussed in #278495 / #279232 when the 5.6 -> 5.8 transition was taking place. The context was doc-base and /usr/sbin/install-docs, but much of the discussion seems valid here too. Particularly this comment from Brendan: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=279232#22 > Even having perl-modules and perl pre-depend on perl-base doesn't > necessarily fix the problem since while that would ensure that perl-base > was upgraded before either of those modules, there's no guarantee that > other packages wouldn't be pre-configured/configured between perl-base > and perl, perl-modules. So while this kind of fixes may work for most cases, there are no guarantees and they may still break for some people. > > 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. In light of the above, I think it is a policy violation and I don't really think we have much choice here. For the gs-common / defoma case, the way out would seem to be something like: - go through the packages depending on defoma in Etch, find broken prerm scripts and make sure they have equivalents in Lenny that survive 'failed-upgrade'. It may be possible to do most of this by changing /usr/bin/dh_installdefoma behaviour and binNMUing the packages, not sure about that. - remove all defoma-app invocations from the 'prerm upgrade' code paths in lenny so we don't hit this again in the future - (optionally) fix /usr/sbin/defoma-app in lenny to fail gracefully when its dependencies are unconfigured, particularly when File::Copy can't be found, to avoid the 'failed-upgrade' path if defoma happens to get upgraded first The debsums issue is quite different, and I'm surprised that Dpkg::Post-Invoke can happen when packages are still unconfigured. Maybe it only bites when there's some other error and the installation is interrupted? As for others, I suppose we'll have to fix them as they show up. It looks like libxml-libxml-perl.prerm is one. A systematical way of finding them could be to unpack new perl and perl-modules on Etch and then doing partial upgrades for all the Etch packages one by one somehow. That would take quite a while, I suppose. I'd love it to be proven wrong somewhere here. -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
