Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC
Niko Tyni writes (Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC): In that case the dependency on perl would be direct, but the script would fail in exactly the same way when a newer perl-modules is unpacked - because Time::Piece needs Time::Local from perl-modules, and that wouldn't be on the search path anymore. Again, that would be an indirect dependency, although of a different kind. I suspect it has more to do with the circular dependency between perl and perl-modules. No, that's not it. At the time when the bug occurs perl has always been happily configured. We see the bug with xfonts-traditional because both (a) it has a trigger and (b) luck means that the usual ordering exposes the bug. But as I explained earlier, this situation is not limited to packages with triggers. It can be repro'd with xfonts-traditional without triggers being involved. I don't quite buy this argument about triggers not being involved. Earlier I described a repro where xfonts-traditional's postinst fails the `configure' operation. The trigger is not a necessary component of the failure. Consider, in a wheezy chroot: ... In this situation dpkg would agree to install and configure a package that Depends on 'file' and uses that command in 'postinst configure', but the configure step would fail. Does that imply that the new libmagic1 package should Break older versions of file? I don't think that makes sense. I think this does't normally actually arise because apt prefers to configure things in a different order. So why does it after s/file/perl/ and s/libmagic1/perl-modules/ ? It looks to me like this new Breaks: requirement arises from the dpkg triggers implementation and possibly concerns only circular dependencies. The loop breaking logic that looks for postinst scripts (policy 7.2) seems related. Clearly we don't have this for triggers, only for the configure step. The loop is nothing to do with it. The problem is that the dependency checking has always been a bit loose in these kind of cases, but it hasn't mattered very much until now. It would be better if dpkg would avoid configuring (or invoking trigger processing for) A when A-B-C and C is not configured, but B is. That's not a practical solution for jessie. I still think the Breaks as suggested earlier is the correct solution. Ian. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC
Niko Tyni writes (Re: Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC): reassign 774844 perl 5.20.1-4 thanks ... Fine by me, I'm not arguing against that. Clearly it's time to stop/postpone the discussion about theoretical wider effects and do what's necessary for jessie. I think so, yes. So reassigning the bug. I'll be uploading the Breaks+Pre-Depends change hopefully tomorrow. Thank you, and thanks for your careful attention and searching questions. Regards, Ian. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC
reassign 774844 perl 5.20.1-4 thanks On Sat, Jan 24, 2015 at 06:39:02PM +, Ian Jackson wrote: It would be better if dpkg would avoid configuring (or invoking trigger processing for) A when A-B-C and C is not configured, but B is. That's not a practical solution for jessie. I still think the Breaks as suggested earlier is the correct solution. Fine by me, I'm not arguing against that. Clearly it's time to stop/postpone the discussion about theoretical wider effects and do what's necessary for jessie. So reassigning the bug. I'll be uploading the Breaks+Pre-Depends change hopefully tomorrow. Thanks, -- 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
Processed: Re: Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC
Processing commands for cont...@bugs.debian.org: reassign 774844 perl 5.20.1-4 Bug #774844 [xfonts-traditional] xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC Bug reassigned from package 'xfonts-traditional' to 'perl'. No longer marked as found in versions xfonts-traditional/1.6. Ignoring request to alter fixed versions of bug #774844 to the same values previously set Bug #774844 [perl] xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC Marked as found in versions perl/5.20.1-4. thanks Stopping processing here. Please contact me if you need assistance. -- 774844: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774844 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC
Ian Jackson ijack...@chiark.greenend.org.uk writes: But it mostly occurs when a dependency is indirected through an intermediate package. That is, A uses some feature in C, but the dependency is declared on B which depends on C. This is (perhaps surprisingly) not particularly common. That's partly because those of us who work on Lintian have been annoying maintainers about this as much as possible to try to get them not to do that. :) But in the case of perl it's nearly universal, because of the policy recommendation to depend on the metapackage `perl' rather than perl-base or perl-modules. I suspect this is an outgrowth of the fact that we've always felt that the split of the perl package was sort of wrong, in the sense that we did it for internal reasons that are valid, but the average user should not perceive it as being divided into multiple packages, and we generally should try to avoid treating it as such. I don't think `requires strict dependencies' is a very useful concept here. That xfonts-traditional uses (in a maintainer script) a perl module which has always been implied by `perl' can hardly be unusual. I don't think it makes sense to regard that as a particularly `strict'. There are certainly other packages in the archive with Perl maintainer scripts, although the ones I'm aware of I don't think use modules that have moved. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC
On Mon, Jan 19, 2015 at 05:09:31PM +, Ian Jackson wrote: Niko Tyni writes (Re: Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC): My point was that this is potentially a much wider issue, not limited to perl. I should reply to this. You are right that it is, potentially, a wider issue. But it mostly occurs when a dependency is indirected through an intermediate package. That is, A uses some feature in C, but the dependency is declared on B which depends on C. I don't think this indirection is the key here. The same issue could just as well have happened if the xfonts-traditional postinst functionality needed for example Time::Piece (which is in the perl package.) In that case the dependency on perl would be direct, but the script would fail in exactly the same way when a newer perl-modules is unpacked - because Time::Piece needs Time::Local from perl-modules, and that wouldn't be on the search path anymore. I suspect it has more to do with the circular dependency between perl and perl-modules. We see the bug with xfonts-traditional because both (a) it has a trigger and (b) luck means that the usual ordering exposes the bug. But as I explained earlier, this situation is not limited to packages with triggers. It can be repro'd with xfonts-traditional without triggers being involved. I don't quite buy this argument about triggers not being involved. Consider, in a wheezy chroot: # apt-get install file # dpkg --unpack libmagic1_5.22+15-1_amd64.deb # from sid # file /usr/bin/perl file: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /usr/lib/x86_64-linux-gnu/libmagic.so.1) file: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by /usr/lib/x86_64-linux-gnu/libmagic.so.1) # dpkg -l file [...] ii file 5.11-2+deb7u6amd64Determines file type using magic numbers In this situation dpkg would agree to install and configure a package that Depends on 'file' and uses that command in 'postinst configure', but the configure step would fail. Does that imply that the new libmagic1 package should Break older versions of file? I don't think that makes sense. So why does it after s/file/perl/ and s/libmagic1/perl-modules/ ? It looks to me like this new Breaks: requirement arises from the dpkg triggers implementation and possibly concerns only circular dependencies. The loop breaking logic that looks for postinst scripts (policy 7.2) seems related. Clearly we don't have this for triggers, only for the configure step. -- 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
Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC
On Sun, Jan 18, 2015 at 10:37:19PM +0100, Andreas Beckmann wrote: On 2015-01-18 18:48, Niko Tyni wrote: a) - make xfonts-traditional 'postinst triggered' survive missing dependencies - make perl-base+perl-modules+perl Break xfonts-traditional older than that What about this rather simple solution: Package: perl-modules Breaks: xfonts-traditional ( 1.7~) The action to achieve is: before the new perl-modules is unpacked (which would break xfonts-traditional.postinst due to missing (or better: relocated) File/Find.pm, ensure xfonts-traditional is either upgraded first or deconfigured - this should be sufficient for any old dpkg not to do trigger processing any more (as long as it is not in a configured state). Unfortunately that doesn't help with partial upgrades. Nothing prevents upgrading and configuring xfonts-traditional first, and only then upgrading the rest of the system. -- 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
Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC
On Mon, 19 Jan 2015 11:39:29 +0100, Andreas Beckmann wrote: Maybe this leads to a rule like: If maintainer scripts (including triggers!) use some module from perl-modules, the package needs to depend on perl-modules. An indirect dependency through perl is not sufficient. This sounds error-prone to me, as maintainers would have to find out which package contains the module, and track this information when modules are moved. I guess Niko's idea of adding a Breaks on the old perl to perl-base and perl-modules is both less work and more reliable. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- BOFH excuse #384: it's an ID-10-T error -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC
On 2015-01-19 09:14, Niko Tyni wrote: On Sun, Jan 18, 2015 at 10:37:19PM +0100, Andreas Beckmann wrote: Package: perl-modules Breaks: xfonts-traditional ( 1.7~) Unfortunately that doesn't help with partial upgrades. Nothing prevents upgrading and configuring xfonts-traditional first, and only then upgrading the rest of the system. OK, how can we prevent trigger processing for xfonts-traditional if perl-modules is not usable? Package: xfonts-traditional Depends: dpkg (= 1.17.triggerfixed), perl-modules seems to work in my manual test. dpkg/jessie seems not to run trigproc if the direct dependency perl-modules is not configured (dpkg/wheezy does) dpkg/jessie (and dpkg/wheezy) run trigproc if the direct dependency perl is confgured, but the indirect dependency perl-modules is only unpacked. Maybe this leads to a rule like: If maintainer scripts (including triggers!) use some module from perl-modules, the package needs to depend on perl-modules. An indirect dependency through perl is not sufficient. Andreas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC
Niko Tyni writes (Re: Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC): My point was that this is potentially a much wider issue, not limited to perl. I should reply to this. You are right that it is, potentially, a wider issue. But it mostly occurs when a dependency is indirected through an intermediate package. That is, A uses some feature in C, but the dependency is declared on B which depends on C. This is (perhaps surprisingly) not particularly common. But in the case of perl it's nearly universal, because of the policy recommendation to depend on the metapackage `perl' rather than perl-base or perl-modules. This is why I think the right fix is to add the Breaks to the perl packages. Andreas wrote: I think this list can be reduced to Uses 'perl stuff that requires strict dependencies' in their maintainer scripts. I don't think `requires strict dependencies' is a very useful concept here. That xfonts-traditional uses (in a maintainer script) a perl module which has always been implied by `perl' can hardly be unusual. I don't think it makes sense to regard that as a particularly `strict'. We see the bug with xfonts-traditional because both (a) it has a trigger and (b) luck means that the usual ordering exposes the bug. But as I explained earlier, this situation is not limited to packages with triggers. It can be repro'd with xfonts-traditional without triggers being involved. I think searching the archive for other packages which are exposed to similar issues with perl would be difficult. At the very least we'd have to search for every package which relies in its postinst on modules which are moving between perl packages. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC
On Sat, Jan 17, 2015 at 04:24:58PM +0100, Andreas Beckmann wrote: On 2015-01-15 21:32, Niko Tyni wrote: So, even if we add the Breaks in perl-modules+perl-base, it looks like something else is needed. AFAICS either we need to somehow ensure that dpkg is upgraded first, or the xfonts-traditional trigger functionality needs to handle missing modules gracefully. Do we have a list of packages that trigger xfonts-traditional? Could they (or some of them or a common ancestor) depend on dpkg (= 1.17.triggerfixed) From the xfonts-traditional triggers file: interest-noawait /usr/share/fonts/X11 interest-noawait /etc/X11/app-defaults/XTerm interest-noawait /etc/X11/fonts/misc/xfonts-base.alias apt-file finds 91 packages in sid matching /usr/share/fonts/X11. That's a bit much. I'd love to hear thoughts on this. Also, my earlier questions still apply: does this imply that all packages with strict versioned dependencies and the like should more or less duplicate that information in Breaks entries ? I think this list can be reduced to Uses 'perl stuff that requires strict dependencies' in their maintainer scripts. My point was that this is potentially a much wider issue, not limited to perl. But concentrating on this specific issue which is clearly RC for jessie: assuming we don't want to change all the 91 font packages, I see these possibilities: a) - make xfonts-traditional 'postinst triggered' survive missing dependencies - make perl-base+perl-modules+perl Break xfonts-traditional older than that b) - make perl-base+perl-modules Break: perl ( 5.20.0~) - make perl-base+perl-modules+perl Pre-Depend on dpkg (= 1.17.17) The second choice is a more generic fix that may benefit other packages too, assuming those Breaks are the correct thing to do. I'm inclined to do b) but at least the predependency needs a discussion on -devel too so I'll go there next. -- 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
Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC
On 2015-01-18 18:48, Niko Tyni wrote: a) - make xfonts-traditional 'postinst triggered' survive missing dependencies - make perl-base+perl-modules+perl Break xfonts-traditional older than that What about this rather simple solution: Package: perl-modules Breaks: xfonts-traditional ( 1.7~) The action to achieve is: before the new perl-modules is unpacked (which would break xfonts-traditional.postinst due to missing (or better: relocated) File/Find.pm, ensure xfonts-traditional is either upgraded first or deconfigured - this should be sufficient for any old dpkg not to do trigger processing any more (as long as it is not in a configured state). I tested this, and it seems to work: Preparing to replace xfonts-traditional 1.6 (using .../xfonts-traditional_1.7.1_all.deb) ... Checking configuration... Unpacking replacement xfonts-traditional ... Preparing to replace perl-modules 5.14.2-21+deb7u2 (using .../perl-modules_5.20.1-4.1_all.deb) ... Unpacking replacement perl-modules ... Selecting previously unselected package libdb5.3:amd64. Unpacking libdb5.3:amd64 (from .../libdb5.3_5.3.28-7~deb8u1_amd64.deb) ... Setting up libdb5.3:amd64 (5.3.28-7~deb8u1) ... Processing triggers for libc-bin ... (Reading database ... 8476 files and directories currently installed.) Preparing to replace perl 5.14.2-21+deb7u2 (using .../pl/./perl_5.20.1-4.1_amd64.deb) ... Unpacking replacement perl ... Preparing to replace libsys-cpu-perl 0.52-3 (using .../libsys-cpu-perl_0.61-1+b1_amd64.deb) ... Unpacking replacement libsys-cpu-perl ... Preparing to replace libtext-iconv-perl 1.7-5 (using .../libtext-iconv-perl_1.7-5+b2_amd64.deb) ... Unpacking replacement libtext-iconv-perl ... Preparing to replace perl-base 5.14.2-21+deb7u2 (using .../perl-base_5.20.1-4.1_amd64.deb) ... Unpacking replacement perl-base ... Setting up perl-base (5.20.1-4.1) ... (Reading database ... 7806 files and directories currently installed.) Preparing to replace liblocale-gettext-perl 1.05-7+b1 (using .../liblocale-gettext-perl_1.05-8+b1_amd64.deb) ... Unpacking replacement liblocale-gettext-perl ... Preparing to replace libgdbm3:amd64 1.8.3-11 (using .../libgdbm3_1.8.3-13.1_amd64.deb) ... Unpacking replacement libgdbm3:amd64 ... Preparing to replace dpkg 1.16.15 (using .../dpkg_1.17.23_amd64.deb) ... Unpacking replacement dpkg ... Setting up dpkg (1.17.23) ... Installing new version of config file /etc/cron.daily/dpkg ... (Reading database ... 7794 files and directories currently installed.) No Pre-Depends or any other fancy stuff needed :-) Andreas xfonts-traditional_with_perl-modules-breaks.log.gz Description: application/gzip
Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC
On 2015-01-15 21:32, Niko Tyni wrote: So, even if we add the Breaks in perl-modules+perl-base, it looks like something else is needed. AFAICS either we need to somehow ensure that dpkg is upgraded first, or the xfonts-traditional trigger functionality needs to handle missing modules gracefully. Do we have a list of packages that trigger xfonts-traditional? Could they (or some of them or a common ancestor) depend on dpkg (= 1.17.triggerfixed) I'd love to hear thoughts on this. Also, my earlier questions still apply: does this imply that all packages with strict versioned dependencies and the like should more or less duplicate that information in Breaks entries ? I think this list can be reduced to Uses 'perl stuff that requires strict dependencies' in their maintainer scripts. Andreas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC
On Fri, Jan 09, 2015 at 09:13:03PM +0200, Niko Tyni wrote: On Thu, Jan 08, 2015 at 04:12:05PM +, Ian Jackson wrote: 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). 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. I have some good news and some bad news. The good news is that those Breaks seem to work fine with apt. I've tested upgrading quite a few small chroots with no ill effects, and also successfully upgraded one larger chroot with libapache2-mod-perl2, spamassassin, and request-tracker4 installed. The bad news is that the Breaks only help with the jessie dpkg. They obviously prevent the scenario where xfonts-traditional is newly installed while the new perl-modules is at 'unpacked', as dpkg now refuses to configure the package because perl is deconfigured. However, simple upgrades involving xfonts-traditional still fail as before. It looks like [1] the wheezy dpkg will still run the xfonts-traditional 'postinst triggered' even when its direct dependency perl is deconfigured. I think this is #671711 (dpkg: runs trigger processing even if depedencies are not satisfied), fixed between wheezy and jessie. So, even if we add the Breaks in perl-modules+perl-base, it looks like something else is needed. AFAICS either we need to somehow ensure that dpkg is upgraded first, or the xfonts-traditional trigger functionality needs to handle missing modules gracefully. I'd love to hear thoughts on this. Also, my earlier questions still apply: does this imply that all packages with strict versioned dependencies and the like should more or less duplicate that information in Breaks entries ? [1] A test case would be (starting in a minimal wheezy chroot): apt-get install xfonts-traditional # from wheezy # (optionally, switch to jessie and apt-get install the newer dpkg) # (the version of xfonts-traditional seems to have no effect here) dpkg --auto-deconfigure --unpack perl-modules_5.20.1-5_all.deb # jessie + the Breaks dpkg -i xfonts-mona_2.90-7_all.deb # both wheezy/jessie With wheezy dpkg, the last command with -D1 (trigger debugging) gives Unpacking xfonts-mona (from xfonts-mona_2.90-7_all.deb) ... D01: trigproc_enqueue_deferred pend=xfonts-traditional:all Setting up xfonts-mona (2.90-7) ... D01: trigproc_run_deferred D01: trigproc xfonts-traditional:all D01: check_triggers_cycle pnow=xfonts-traditional:all Processing triggers for xfonts-traditional ... Generating fonts... Can't locate File/Find.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at /usr/bin/update-xfonts-traditional line 9. and with jessie dpkg just Unpacking xfonts-mona (2.90-7) ... D01: trigproc_enqueue_deferred pend=xfonts-traditional:all Setting up xfonts-mona (2.90-7) ... D01: trigproc_run_deferred D01: trigproc xfonts-traditional:all (The trigger gets run successfully later if perl is upgraded and configured.) -- 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
Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC
On Thu, Jan 08, 2015 at 04:12:05PM +, 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
Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC
Control: found -1 xfonts-traditional/1.6 Control: notfound -1 xfonts-traditional/1.7.1 Andreas Beckmann writes (Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC): Package: xfonts-traditional Version: 1.7.1 Thanks for the report. This is definitely a bad bug which must be fixed for jessie. At the point where the error occurs we have these packages installed/unpacked: dpkg: wheezy perl-base: wheezy (no File/Find.pm, yet) perl-modules: jessie (no File/Find.pm any longer) xfonts-traditional: wheezy i.e. the triggers from xfonts-traditional/wheezy are run by dpkg/wheezy. What triggered them btw? I think that the target package for this bug is perhaps wrong. (That is, that the change will have to be made to a different package.) Certainly the version is wrong: at the point where this bug occurs, xfonts-traditional_1.7.1_all.deb has not even been touched. 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 But xfonts-traditional depends on `perl', not `perl-modules' or `perl-base'. And `perl' is not deconfigured merely because one of its dependencies goes from configured to unpacked. So at this point xfonts-traditional's postinst will run but the actual purpose of its dependency on `perl' is not fully satisfied. The postinst will fail. This arises from the fact that in dpkg the `dependencies are configured when postinst is run' requirement is not transitive: it doesn't apply to the dependencies of one's dependencies. AFAICT xfonts-traditional's use of dependencies conforms to the recommendation in the perl policy: https://www.debian.org/doc/packaging-manuals/perl-policy/ch-programs.html 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). That declares it necessary to deconfigure perl (wheezy) to install perl-modules (jessie). perl (wheezy) cannot be re-configured until perl-modules (which it depends on) is re-configured, but perl-modules (jessie) depends on perl-base (jessie) so apt and dpkg will have to unpack and configure perl-base (jessie) first. Thus it will not be possible for `perl' to be `installed' while File/Find.pm is absent. And xfonts-traditional's (or some other client package)'s postinst won't run until `perl' is `installed' again. Since File/Find.pm moved to perl-base, maybe the Depends: perl can be changed to Depends: perl-base (= 5.20.1-3~) and perl-modules could add a Breaks: xfonts-traditional (= 1.7.1) But, firstly, that's not an entirely accurate description of xfonts-traditional dependencies. The package does in fact work with older perls. And, this approach suggests that perl-modules should grow a Breaks for every package in the archive which uses File::Find, which doesn't seem like a very good approach. Regards, Ian. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC
Processing control commands: found -1 xfonts-traditional/1.6 Bug #774844 [xfonts-traditional] xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC Marked as found in versions xfonts-traditional/1.6. notfound -1 xfonts-traditional/1.7.1 Bug #774844 [xfonts-traditional] xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC No longer marked as found in versions xfonts-traditional/1.7.1. -- 774844: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774844 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC
Package: xfonts-traditional Version: 1.7.1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'wheezy'. It installed fine in 'wheezy', then the upgrade to 'sid' fails. From the attached log (scroll to the bottom...): Preparing to replace perl-modules 5.14.2-21+deb7u2 (using .../perl-modules_5.20.1-4_all.deb) ... Unpacking replacement perl-modules ... Selecting previously unselected package libdb5.3:amd64. Unpacking libdb5.3:amd64 (from .../libdb5.3_5.3.28-9_amd64.deb) ... Processing triggers for xfonts-traditional ... Generating fonts... Can't locate File/Find.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at /usr/bin/update-xfonts-traditional line 9. BEGIN failed--compilation aborted at /usr/bin/update-xfonts-traditional line 9. dpkg: error processing xfonts-traditional (--unpack): subprocess installed post-installation script returned error exit status 2 Errors were encountered while processing: xfonts-traditional This seems to be a regression by dpkg having added a versioned Breaks due to trigger cycles ... At the point where the error occurs we have these packages installed/unpacked: dpkg: wheezy perl-base: wheezy (no File/Find.pm, yet) perl-modules: jessie (no File/Find.pm any longer) xfonts-traditional: wheezy i.e. the triggers from xfonts-traditional/wheezy are run by dpkg/wheezy. What triggered them btw? Since File/Find.pm moved to perl-base, maybe the Depends: perl can be changed to Depends: perl-base (= 5.20.1-3~) and perl-modules could add a Breaks: xfonts-traditional (= 1.7.1) cheers, Andreas xfonts-traditional_1.7.1.log.gz Description: application/gzip
Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC
(Resending with debian-perl in the CC.) Andreas Beckmann writes (Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC): Package: xfonts-traditional Version: 1.7.1 Thanks for the report. This is definitely a bad bug which must be fixed for jessie. At the point where the error occurs we have these packages installed/unpacked: dpkg: wheezy perl-base: wheezy (no File/Find.pm, yet) perl-modules: jessie (no File/Find.pm any longer) xfonts-traditional: wheezy i.e. the triggers from xfonts-traditional/wheezy are run by dpkg/wheezy. What triggered them btw? I think that the target package for this bug is perhaps wrong. (That is, that the change will have to be made to a different package.) Certainly the version is wrong: at the point where this bug occurs, xfonts-traditional_1.7.1_all.deb has not even been touched. 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 But xfonts-traditional depends on `perl', not `perl-modules' or `perl-base'. And `perl' is not deconfigured merely because one of its dependencies goes from configured to unpacked. So at this point xfonts-traditional's postinst will run but the actual purpose of its dependency on `perl' is not fully satisfied. The postinst will fail. This arises from the fact that in dpkg the `dependencies are configured when postinst is run' requirement is not transitive: it doesn't apply to the dependencies of one's dependencies. AFAICT xfonts-traditional's use of dependencies conforms to the recommendation in the perl policy: https://www.debian.org/doc/packaging-manuals/perl-policy/ch-programs.html 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). That declares it necessary to deconfigure perl (wheezy) to install perl-modules (jessie). perl (wheezy) cannot be re-configured until perl-modules (which it depends on) is re-configured, but perl-modules (jessie) depends on perl-base (jessie) so apt and dpkg will have to unpack and configure perl-base (jessie) first. Thus it will not be possible for `perl' to be `installed' while File/Find.pm is absent. And xfonts-traditional's (or some other client package)'s postinst won't run until `perl' is `installed' again. Since File/Find.pm moved to perl-base, maybe the Depends: perl can be changed to Depends: perl-base (= 5.20.1-3~) and perl-modules could add a Breaks: xfonts-traditional (= 1.7.1) But, firstly, that's not an entirely accurate description of xfonts-traditional dependencies. The package does in fact work with older perls. And, this approach suggests that perl-modules should grow a Breaks for every package in the archive which uses File::Find, which doesn't seem like a very good approach. Regards, Ian. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
