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 nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org