Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC

[Niko Tyni]

On Thu, Jan 08, 2015 at 04:12:05PM +0000, Ian Jackson wrote:
> Andreas Beckmann writes ("Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC"):

> > Since File/Find.pm moved to perl-base, [...]

> I think that the current dependency structure would permit:
>  * Start with wheezy, without xfonts-traditional
>  * Unpack perl-modules from jessie but do not configure it
>  * Install xfonts-traditional

Yes, my tests indicate that dpkg will agree to do that if so instructed,
and the xfonts-traditional 'postinst configure' run will then fail.

> If my scenario above is correct, this problem is not confined to
> packages involving triggers, nor necessarily to xfonts-traditional.
> Rather the problem is that the policy implies that most packages will
> depend on just `perl', but `perl' can be `installed' despite some of
> the functionality it is supposed to provide (File/Find.pm in this
> case) being missing.
> 
> I think the right fix therefore has to be in the Perl packages.
> 
> Here is a suggestion: have perl-modules (jessie) declare a Breaks on
> perl (wheezy).

I suppose we can do that if it helps and doesn't break other things,
but I'd like to understand this requirement a bit better first.

There are probably lots of small package sets in the archive with strict
versioned dependencies because they must be upgraded more or less in
lockstep to stay functional.  Think foo_X.Y Depends: foo-data (=X.Y)
for example. So should every such newer foo-data package Break older
foo packages so that those get deconfigured during upgrades?

Also, File::Find hasn't moved to perl-base, although that was considered
and a few other modules did. Rather, every oldstable->stable upgrade
since etch->lenny in 2009 has had the new perl-modules package breaking
functionality of the old perl package, because the library path
(/usr/share/perl/<VERSION>/) changes between major upgrades. Likewise,
unpacking a newer perl-base will make the old perl and perl-modules
packages nonfunctional until they are upgraded.

(I've tested this by installing the dependencies of xfonts-traditional
 on wheezy and then unpacking a newer perl-base. That will make later
 manual "dpkg -i" installation of xfonts-traditional fail in "postinst
 configure" because Data::Dumper is not on the new library path yet and
 is therefore "missing".)

So we seem to have managed three major upgrades without deconfiguring
the perl package during them.  My best guess is that this hasn't been a
problem earlier because apt (and other dpkg frontends?) will not tell dpkg
to configure a package if its recursive dependencies aren't configured
yet, or something like that. So this seems limited to triggers after all?

If perl-modules must Break older perl versions, so must apparently
perl-base.  Also, there are currently eight packages [1] in sid that
depend on perlapi-xxx and perl-base but not on perl. Should we make
perl-base Break older versions of those too, as they will be nonfunctional
until upgraded if perl-base is upgraded first? While this can probably
be done for wheezy->jessie, it doesn't seem to scale in the general case,
and binNMU version skew between architectures may make it rather ugly.

Anyway, I guess I'll experiment with the perl-modules+perl-base -> perl
Breaks entries to see how well apt handles such upgrades, as I'm slightly
worried about that.

[1] these would be
 libapparmor-perl
 libapt-pkg-perl
 liblocale-gettext-perl
 libtext-charwidth-perl
 libtext-iconv-perl
 libuuid-perl
 libpurple0
 pidgin

-- 
Niko Tyni   ntyni at debian.org