Bug#657940: perl: upgrade problem if defoma-app is called from a maintainer-script in the middle of the perl upgrade

[Niko Tyni]

On Mon, Jan 30, 2012 at 03:35:51AM +0100, Andreas Beckmann wrote:
> Package: perl
> Version: 5.14.2-6

> The problem happens during the upgrade of libwmf0.2-7, the old prerm
> calls defoma app which fails:
 
Oh my, the squeeze defoma-app version was still broken in this regard. It
would have been nice if we'd fixed it when this last broke with Etch ->
Lenny (see #495359). 

>   Preparing to replace libwmf0.2-7 0.2.8.4-6.1+b1 (using .../libwmf0.2-7_0.2.8.4-10_amd64.deb) ...
>   Can't locate File/Copy.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at /usr/bin/defoma-app line 7.
>   BEGIN failed--compilation aborted at /usr/bin/defoma-app line 7.
>   dpkg: warning: subprocess old pre-removal script returned error exit status 2
>   dpkg - trying script from the new package instead ...
>   dpkg: error processing /var/cache/apt/archives/libwmf0.2-7_0.2.8.4-10_amd64.deb (--unpack):
>    there is no script in the new version of the package - giving up

> File::Copy gets moved while perl-modules is updated, but the new
> location is not used before perl-base is updated. Inbetween defoma-app
> may not be used.
> 
> While this could be worked around libwmf0.2-7 by adding a dummy postrm,

I think that should be a dummy prerm?

>     <jcristau> anbe: if we can find a fix in perl or defoma instead i think
>         that'd be better
>     <jcristau> rather than finding all packages that might possibly call
>         defoma-app in the middle of the perl upgrade
> 
> So I try assigning this to perl first, perhaps an appropriate
>   Breaks: defoma (<< $squeeze+1)
> or other fix can be added to one of the perl packages.

As it looks like defoma is finally fixed now (see #494106), I think we'd
be fine if the wheezy perl-base had a Conflicts: defoma (<< 0.11.12).
I don't think a Breaks: entry would be enough.

OTOH, there are only a handful of packages depending on defoma left,
so it might actually be feasible to check them all. For comparison,
quoting myself in 2008 (#495359):

> I have now gone through all the packages in Etch depending on defoma.
> The only one that fails upgrades is gs-common. I found 14 packages whose
> 'old-prerm upgrade' fails, but 'new-prerm failed-upgrade' succeeds.

I doubt the problem is more widespread now.
-- 
Niko Tyni   ntyni at debian.org