Summary: | dev-perl/XML-LibXML installs ParserDetails.ini but does not claim it nor clean it up when the package is upgraded/removed | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dave Kemper <saint.snit> |
Component: | [OLD] Development | Assignee: | Paul Varner (RETIRED) <fuzzyray> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | perl |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=684720 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Dave Kemper
2014-04-29 17:30:13 UTC
Also, after the emerge and perl-cleaner, no packages claim the files in question: $ portageq owners / /usr/lib/perl5/5.12.4/i686-linux/Encode/ConfigLocal.pm None of the installed packages claim these files: /usr/lib/perl5/5.12.4/i686-linux/Encode/ConfigLocal.pm $ portageq owners / /usr/lib/perl5/vendor_perl/5.12.4/XML/SAX/ParserDetails.ini None of the installed packages claim these files: /usr/lib/perl5/vendor_perl/5.12.4/XML/SAX/ParserDetails.ini $ Since I didn't put the files there, some prior emerge must have done it, which means something is not being cleaned up properly in order for them to be unclaimed now. "some prior emerge must have done it" Nah, some prior run of perl-cleaner did it, or some other perl code was loaded which modified/created those files post-install while running as a sufficiently privileged user. You are correct that I cannot definitively point to an emerge being responsible. What's your basis for definitively saying one wasn't? perl-5.12.4-r1 was the very first perl emerged onto this system, in Jun 2012. It remained in place until yesterday's upgrade to perl-5.16.3. So I would've had no reason to run perl-cleaner before. I only install/uninstall software on this machine through portage, so I can't imagine what else might have touched those files. Hmm. ParserDetails.ini has a current version on the system, but it also isn't claimed by portage: $ ls -lt /usr/lib/perl5/vendor_perl/*/XML/SAX/ParserDetails.ini -rw-r--r-- 1 root root 200 Apr 29 03:35 /usr/lib/perl5/vendor_perl/5.16.3/XML/SAX/ParserDetails.ini -rw-r--r-- 1 root root 200 Mar 29 15:32 /usr/lib/perl5/vendor_perl/5.12.4/XML/SAX/ParserDetails.ini $ portageq owners / /usr/lib/perl5/vendor_perl/*/XML/SAX/ParserDetails.ini None of the installed packages claim these files: /usr/lib/perl5/vendor_perl/5.12.4/XML/SAX/ParserDetails.ini /usr/lib/perl5/vendor_perl/5.16.3/XML/SAX/ParserDetails.ini The timestamp of the 5.16.3 ParserDetails corresponds to the 81 perl package reinstalls triggered by perl-clean. That of the 5.12.4 version roughly corresponds to when I emerged two perl packages: dev-perl/XML-LibXML-2.1.400, upgrading from 1.900.0 dev-perl/File-MimeInfo-0.170.0, upgrading from 0.150.0 Unfortunately, /var/log/emerge.log is stingy with timestamps, so it's hard to pinpoint installation times precisely, especially for previous versions. But for the currently installed versions, I can go by other files installed by the respective packages: $ ls -l /usr/share/doc/XML-LibXML-2.1.400/README.bz2 -rw-r--r-- 1 root root 3950 Apr 29 03:35 /usr/share/doc/XML-LibXML-2.1.400/README.bz2 $ ls -l /usr/share/doc/File-MimeInfo-0.170.0/README.bz2 -rw-r--r-- 1 root root 722 Apr 29 03:37 /usr/share/doc/File-MimeInfo-0.170.0/README.bz2 Thus, it sure does appear that ParserDetails.ini is placed on the system by the dev-perl/XML-LibXML emerge. Concerning the other leftover file: there is no other version of ConfigLocal.pm on the system: $ ls -t --full-time /usr/lib/perl5/*/*/*/ConfigLocal.pm /usr/sbin/perl-cleaner -rwxr-xr-x 1 root root 15947 2012-06-22 01:57:17.000000000 -0500 /usr/sbin/perl-cleaner -rw-r--r-- 1 root root 172 2012-06-22 01:57:05.000000000 -0500 /usr/lib/perl5/5.12.4/i686-linux/Encode/ConfigLocal.pm Also, since ConfigLocal.pm is older than perl-cleaner, perl-cleaner cannot have put it there. (app-admin/perl-cleaner was first installed on June 22, 2012, and has never been updated.) More specifically, the act of running perl-cleaner cannot have put it there; I cannot rule out the possibility that that the emerge of app-admin/perl-cleaner did so, though this strikes me as rather unlikely. For that matter, app-admin/perl-cleaner-2.7 was only the third perl-related package ever installed on the system. The two that preceded it were sys-devel/libperl-5.10.1 and dev-lang/perl-5.12.4-r1, also both installed on June 22, 2012. So one of those almost certainly put ConfigLocal.pm in place. I now see the same bug when upgrading from dev-lang/perl-5.16.3 to 5.18.2-r1. "perl-cleaner --all" ended with the output: * The following files remain. These were either installed by hand * or edited. This script cannot deal with them. /usr/lib/perl5/5.12.4/i686-linux/Encode/ConfigLocal.pm /usr/lib/perl5/vendor_perl/5.12.4/XML/SAX/ParserDetails.ini /usr/lib/perl5/vendor_perl/5.16.3/XML/SAX/ParserDetails.ini The first two items were reported back in comment #0; the third is new to this upgrade. As in the prior case, I have never altered anything by hand under /usr/lib, nor used anything but portage to change the system. Using logic similar to that of comment #4, I note that although portage claims to not know who owns the current version of this file: $ portageq owners / /usr/lib/perl5/vendor_perl/5.18.2/XML/SAX/ParserDetails.ini None of the installed packages claim these files: /usr/lib/perl5/vendor_perl/5.18.2/XML/SAX/ParserDetails.ini timestamp evidence shows that the package dev-perl/XML-LibXML-2.1.400-r1 (which admits to owning /usr/share/doc/XML-LibXML-2.1.400-r1/README.bz2) is the likely culprit to have installed the mystery ParserDetails.ini: $ ls -l /usr/share/doc/XML-LibXML-2.1.400-r1/README.bz2 /usr/lib/perl5/vendor_perl/5.18.2/XML/SAX/ParserDetails.ini -rw-r--r-- 1 root root 200 Sep 22 17:58 /usr/lib/perl5/vendor_perl/5.18.2/XML/SAX/ParserDetails.ini -rw-r--r-- 1 root root 3950 Sep 22 17:57 /usr/share/doc/XML-LibXML-2.1.400-r1/README.bz2 So the source of the problem seems to be that because portage is unaware dev-perl/XML-LibXML places ParserDetails.ini on the system, it cannot clean it up when the package is removed. Updating the summary to more precisely reflect the problem. (I am disregarding the leftover ConfigLocal.pm reported in comment #0 because, as comment #5 indicates, this file does not seem to exist any longer in current versions of perl packages.) A probable explanation is the "post_" things in XML-LibXML These are plausibly causing files to be inflated after installation in such a way portage can't track them. --- pkg_postinst() { pkg_update_parser add XML::LibXML::SAX::Parser pkg_update_parser add XML::LibXML::SAX } pkg_postrm() { pkg_update_parser remove XML::LibXML::SAX::Parser pkg_update_parser remove XML::LibXML::SAX } pkg_update_parser() { # pkg_update_parser [add|remove] $parser_module local action=$1 local parser_module=$2 if [[ "$ROOT" = "/" ]] ; then einfo "Update Parser: $1 $2" perl -MXML::SAX -e "XML::SAX->${action}_parser(q(${parser_module}))->save_parsers()" \ || ewarn "Update Parser: $1 $2 failed" else elog "To $1 $2 run:" elog "perl -MXML::SAX -e 'XML::SAX->${action}_parser(q(${parser_module}))->save_parsers()'" fi } --- > A probable explanation is the "post_" things in XML-LibXML
Thanks, Kent. What is the next step to confirm or refute this probable explanation?
I think the contents of that file might be enlightening. Here, I think the right approach would be to have a XML-SAX provide that file stock instead of creating it in post-install, and instead, only modifying it post-install, especially seeing the other 3 ebuilds that use this file depend on XML-SAX. That file could possibly be CONFIG_PROTECT'd too. As it stands, 3 ebuilds sharing the same copy-pasted code seems bad and could be grounds for an eclass, or even a utility function in perl-module.eclass ( or maybe a new eclass for misc perl functions ). grep XML::SAX /usr/portage/dev-perl/*/*.ebuild /usr/portage/dev-perl/XML-LibXML/XML-LibXML-2.1.400-r1.ebuild: pkg_update_parser add XML::LibXML::SAX::Parser /usr/portage/dev-perl/XML-LibXML/XML-LibXML-2.1.400-r1.ebuild: pkg_update_parser add XML::LibXML::SAX /usr/portage/dev-perl/XML-LibXML/XML-LibXML-2.1.400-r1.ebuild: pkg_update_parser remove XML::LibXML::SAX::Parser /usr/portage/dev-perl/XML-LibXML/XML-LibXML-2.1.400-r1.ebuild: pkg_update_parser remove XML::LibXML::SAX /usr/portage/dev-perl/XML-LibXML/XML-LibXML-2.1.400-r1.ebuild: perl -MXML::SAX -e "XML::SAX->${action}_parser(q(${parser_module}))->save_parsers()" \ /usr/portage/dev-perl/XML-LibXML/XML-LibXML-2.1.400-r1.ebuild: elog "perl -MXML::SAX -e 'XML::SAX->${action}_parser(q(${parser_module}))->save_parsers()'" /usr/portage/dev-perl/XML-SAX-Expat/XML-SAX-Expat-0.400.0.ebuild: pkg_update_parser add XML::SAX::Expat /usr/portage/dev-perl/XML-SAX-Expat/XML-SAX-Expat-0.400.0.ebuild: pkg_update_parser remove XML::SAX::Expat /usr/portage/dev-perl/XML-SAX-Expat/XML-SAX-Expat-0.400.0.ebuild: perl -MXML::SAX -e "XML::SAX->${action}_parser(q(${parser_module}))->save_parsers()" \ /usr/portage/dev-perl/XML-SAX-Expat/XML-SAX-Expat-0.400.0.ebuild: elog "perl -MXML::SAX -e 'XML::SAX->${action}_parser(q(${parser_module}))->save_parsers()'" /usr/portage/dev-perl/XML-SAX-Expat/XML-SAX-Expat-0.500.0.ebuild: pkg_update_parser add XML::SAX::Expat /usr/portage/dev-perl/XML-SAX-Expat/XML-SAX-Expat-0.500.0.ebuild: pkg_update_parser remove XML::SAX::Expat /usr/portage/dev-perl/XML-SAX-Expat/XML-SAX-Expat-0.500.0.ebuild: perl -MXML::SAX -e "XML::SAX->${action}_parser(q(${parser_module}))->save_parsers()" \ /usr/portage/dev-perl/XML-SAX-Expat/XML-SAX-Expat-0.500.0.ebuild: elog "perl -MXML::SAX -e 'XML::SAX->${action}_parser(q(${parser_module}))->save_parsers()'" /usr/portage/dev-perl/XML-SAX-Expat/XML-SAX-Expat-0.510.0.ebuild: pkg_update_parser add XML::SAX::Expat /usr/portage/dev-perl/XML-SAX-Expat/XML-SAX-Expat-0.510.0.ebuild: pkg_update_parser remove XML::SAX::Expat /usr/portage/dev-perl/XML-SAX-Expat/XML-SAX-Expat-0.510.0.ebuild: perl -MXML::SAX -e "XML::SAX->${action}_parser(q(${parser_module}))->save_parsers()" \ /usr/portage/dev-perl/XML-SAX-Expat/XML-SAX-Expat-0.510.0.ebuild: elog "perl -MXML::SAX -e 'XML::SAX->${action}_parser(q(${parser_module}))->save_parsers()'" /usr/portage/dev-perl/XML-SAX/XML-SAX-0.990.0-r1.ebuild: pkg_update_parser add XML::SAX::PurePerl /usr/portage/dev-perl/XML-SAX/XML-SAX-0.990.0-r1.ebuild: perl -MXML::SAX -e "XML::SAX->${action}_parser(q(${parser_module}))->save_parsers()" \ /usr/portage/dev-perl/XML-SAX/XML-SAX-0.990.0-r1.ebuild: elog "perl -MXML::SAX -e 'XML::SAX->${action}_parser(q(${parser_module}))->save_parsers()'" Though I'm completely convinced those XML::SAX invocations *are* what creates that file: https://metacpan.org/source/GRANTM/XML-SAX-0.99/SAX.pm#L20 I may even request upstream add support for a path in /etc instead if that makes sense to everyone else. Then we can just create such a file and avoid this visibility problem entirely. (In reply to Kent Fredric from comment #12) > I may even request upstream add support for a path in /etc instead if that > makes sense to everyone else. Judging by who's commented on this bug, "everyone" seems to be you and me. I have no preference whatsoever on how the fix is implemented. Expcetedly, this problem still appears in the 5.18.2-r2 to 5.20.1-r4 upgrade. The last few lines output by "perl-cleaner --all" are: * The following files remain. These were either installed by hand * or edited. This script cannot deal with them. /usr/lib/perl5/vendor_perl/5.12.4/XML/SAX/ParserDetails.ini /usr/lib/perl5/vendor_perl/5.16.3/XML/SAX/ParserDetails.ini /usr/lib/perl5/vendor_perl/5.18.2/XML/SAX/ParserDetails.ini (In reply to Dave Kemper from comment #14) > Expcetedly, this problem still appears in the 5.18.2-r2 to 5.20.1-r4 > upgrade. The last few lines output by "perl-cleaner --all" are: > > * The following files remain. These were either installed by hand > * or edited. This script cannot deal with them. > > /usr/lib/perl5/vendor_perl/5.12.4/XML/SAX/ParserDetails.ini > /usr/lib/perl5/vendor_perl/5.16.3/XML/SAX/ParserDetails.ini > /usr/lib/perl5/vendor_perl/5.18.2/XML/SAX/ParserDetails.ini For now, because its doubted that there is an automatic sane way to handle this at the perl-itself/perl-cleaner level ( and it needs to be fixed in LibXML somehow ) Until a proper fix goes in, you can just clean up that cruft yourself with rm and then rmdir the empty dirs as need be =). Because I don't think whatever solution we create will nuke all of them. (In reply to Kent Fredric from comment #15) > its doubted that there is an automatic sane way to handle this at the > perl-itself/perl-cleaner level ( and it needs to be fixed in LibXML somehow ) Right, I don't see it as a perl or a perl-cleaner problem, but an XML-LibXML installation problem. The fact that portage is unaware of even the current version of the file on the system tells me there's a problem in the package that puts the file there. > I don't think whatever solution we create will nuke all of them. Yeah, I wouldn't expect it to, but as long as they're not hurting anything, I'll clear them out once new ones stop being left behind. *** This bug has been marked as a duplicate of bug 456938 *** |