cil packages fail to uninstall on lucid->precise upgrade due to prerm script use of perl-modules via /usr/share/cli-common/gac-package-remove -> /usr/share/cli-common/runtimes.d/mono (Can't locate File/Basename.pm in @INC)

lucid's prerm does:

if [ "$1" = "remove" ] || [ "$1" = "upgrade" ] && [ -x /usr/share/cli-common/gac-package-remove ]; then
        /usr/share/cli-common/gac-package-remove libgnomedesktop2.20-cil
fi

This seems to crash when calling gac-package-remove, which I assume is a Perl script. Seems lucid is missing a dependency there, or the dependency has already been removed/is being upgraded.

This is hopefully fixable by doing a precise upload and handle the failure in prerm "$1" = "failed-upgrade". (See http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase).

Chris, as you are most familiar with the Mono packages, can you please have a look at this? Thanks!

This problem is hitting the current main-all upgrade test with a different package affected (libqyoto4.5-cil). cli-common is *not* missing a dependency, it depends on perl-modules as it should; but the new perl-modules is unpacked but not actually usable because the version of perl-base unpacked on the system doesn't match.

See bug #901741 for some more analysis of this general problem wrt perl on the upgrade.

Sticking this on cli-common for the time being, as the package providing the perl script that depends on File::Basename; not sure if we'll be fixing it there or elsewhere.

actually, the script is in mono-gac, not in cil-common.

The /usr/share/cli-common/runtimes.d/mono in lucid calls 'use File::Basename', but it doesn't actually *use* it. The only uses of basename/dirname are embedded in a system() call:

    my $cmd = "(cd `dirname $dll` && "
        . "/usr/bin/gacutil -i `basename $dll`"
           . " > /dev/null)";
    system($cmd) == 0 or die "E: installing Assembly $dll failed\n";

So that's not using File::Basename at all. Dropping this spurious 'use' in SRU may be enough to fix this upgrade problem.

I think we should get this fixed in Debian and then get the Debian Perl maintainers to add Conflicts as appropriate (there's already a reasonable list of such; if I remember correctly, Breaks is too weak). Obviously we can apply those changes locally in Ubuntu if necessary.

I agree that simply removing 'use File::Basename;' looks as though it should be sufficient.

... by which I mean that I don't think an SRU is either necessary or sufficient. I've looked into mono-gac's dependency structure, and I see no reason why apt would have trouble at least unpacking the new version before perl-base.

This bug is currently a blocker in automated upgrade testing that may be hiding other upgrade bugs, so I've gone ahead with uploading the mono change to the freeze queue and will follow up with perl tomorrow morning (unless someone beats me to it).

This bug was fixed in the package mono - 2.10.8.1-1ubuntu1

---------------
mono (2.10.8.1-1ubuntu1) precise; urgency=low

  * debian/mono.runtime-script: Don't use File::Basename, because it's not
    actually being *used*, and the 'use' statement causes failures if this
    script is called while perl-base and perl-modules are not in a consistent
    state. LP: #948848.
 -- Steve Langasek <email address hidden> Thu, 22 Mar 2012 23:00:53 -0700

This bug was fixed in the package perl - 5.14.2-6ubuntu2

---------------
perl (5.14.2-6ubuntu2) precise; urgency=low

  * Have perl, perl-modules, and perl-base conflict with versions of
    mono-gac requiring File::Basename, to ensure a smooth upgrade from lucid.
    LP: #948848.
 -- Steve Langasek <email address hidden> Fri, 23 Mar 2012 07:59:20 -0700