I ran `perl-cleaner all`, but perl-core/DB_File and net-analyzer/net-snmp have not been updated. /usr/lib/perl5/ |-- 5.8.5 | `-- i686-linux | |-- CORE | | |-- libperl.so -> ../../../../libperl.so.1.5.8 | | |-- libperl.so.1 -> ../../../../libperl.so.1.5.8 | | `-- libperl.so.1.5.8 -> ../../../../libperl.so.1.5.8 | |-- DB_File.pm | |-- auto | | `-- DB_File | | |-- DB_File.bs | | |-- DB_File.so | | `-- autosplit.ix /usr/lib/perl5/site_perl |-- 5.8.5 | `-- i686-linux | |-- Bundle | | `-- Makefile.subs.pl | |-- NetSNMP | | |-- ASN.pm | | |-- OID.pm | | |-- TrapReceiver.pm | | |-- agent | | | |-- default_store.pm | | | `-- netsnmp_request_infoPtr.pm | | |-- agent.pm | | `-- default_store.pm | |-- SNMP.pm | `-- auto | |-- Bundle | | `-- NetSNMP | |-- NetSNMP | | |-- ASN | | | |-- ASN.bs | | | |-- ASN.so | | | `-- autosplit.ix | | |-- OID | | | |-- OID.bs | | | |-- OID.so | | | `-- autosplit.ix | | |-- TrapReceiver | | | |-- TrapReceiver.bs | | | |-- TrapReceiver.so | | | `-- autosplit.ix | | |-- agent | | | |-- agent.bs | | | |-- agent.so | | | |-- autosplit.ix | | | `-- default_store | | | |-- autosplit.ix | | | |-- default_store.bs | | | `-- default_store.so | | `-- default_store | | |-- autosplit.ix | | |-- default_store.bs | | `-- default_store.so | `-- SNMP
and you re-emerged them by hand too? (note in the perl ebuilds asks that you try them by hand before giving up and submitting a bug)(doesn't excuse why they weren't caught though)
Michael, shouldn't this work flawlessly w/o inspecting the directories by hand? :) No biggie of course - unless we try to support reverse dependencies out of the box at some point - but still a bug, imho. DB_File worked fine, there seems to be a problem with autoconf, though: >>> Unpacking net-snmp-5.2.1.tar.gz to /var/tmp/portage/net-snmp-5.2.1-r1/work * Applying net-snmp-5.2.1-fix-insecure-fixproc.diff ... [ ok ] * Applying net-snmp-5.2.1-conf-elf-rpm-bz2.patch ... [ ok ] * Applying net-snmp-lm_sensors.patch ... [ ok ] * Replacing obsolete head/tail with POSIX compliant ones * - fixed aclocal.m4 * - fixed configure * - fixed configure.in * - fixed dist/net-snmp-solaris-build/DEVENV * - fixed dist/net-snmp-solaris-build/elfdepend.sh * - fixed local/snmp-ucd.sh * - fixed snmplib/snmpusm.c >>> Source unpacked. FATAL ERROR: Autoconf version 2.59 or higher is required for this script Calling `autoconf-2.59` instead `autoconf` works, adding WANT_AUTOCONF="2.5" to the ebuild does not. Don't know why this wasn't an issue previously - autoconf-wrapper defaults changed or something?
(In reply to comment #2) > there seems to be a problem with autoconf, though: That's already fixed, see Bug 97470 ;)
(In reply to comment #2) > Michael, shouldn't this work flawlessly w/o inspecting the directories by hand? Of course it should, but nothing is perfect. And the problem with DB_File was just tracked down for another bug - bad Makefile.PL was ignoring the vendor specific directive and installing into the core perl area. Net-SNMP doesn't look like it was installed by gentoo. Did you maybe install it with an older g-cpan or by hand at some point? (For starters, its in the wrong place, and we don't give you the bundle - hence why it wasn't caught). Not sure about the autoconf part (I don't have anything to do with it really), but if it persists after I finish cleaning up the mess-that-shouldn't-have-been with the perl upgrades I can revisit this with you if you want.
>Net-SNMP doesn't look like it was installed by gentoo. No, standard Gentoo install. Regarding autoconf, I guess it will be the bug Jakub (thanks!) points to. Never meant that this has anything to do with this script. There's just no usable log file / error output. Back to perl-cleaner: - The log doesn't tell me, if an ebuild has been rebuilt or not, so it's more or less only useful to find out if there is a problem with the script itself. As a user I really don't want to dig through every single script directory (be it perl, python, ruby, whatever), if an update went fine. - Would it harm to add a check for .pm files in older perl directories and compare against /var/db/pkg/*/*/CONTENTS as a last step? DB_File would have been found this way and everything else installed via emerge should be, too. - Minor issues: + `find` printed out lines about non-existing directories a few times. Could you 2> /dev/null this output (in stable versions at least)? + Printing an empty line between the different steps the script performs would be nice.
(In reply to comment #5) > No, standard Gentoo install. Do you know what package provided it? That isn't from dev-perl/Net-SNMP, I checked before making grand claims :) > > Back to perl-cleaner: > > - The log doesn't tell me, if an ebuild has been rebuilt or not, so it's more or > less only useful to find out if there is a problem with the script itself. As a > user I really don't want to dig through every single script directory (be it > perl, python, ruby, whatever), if an update went fine. The logfile is a log of what went to your screen - maybe in the future we can do what you are asking for (list of errors/successes only), but not right now :) > - Would it harm to add a check for .pm files in older perl directories and > compare against /var/db/pkg/*/*/CONTENTS as a last step? DB_File would have been > found this way and everything else installed via emerge should be, too. Funny, isn't this enough: for file in $(find $DIR -iname "*.pm" -type f|grep -v "${PERL_VERSION}"); do (ie, we already do that) The problem with DB_File had nothing to do with perl-cleaner, actually, and everything to do with it being missinstalled because of a bad Makefile.PL and therefore confusing portage as to what package owned it and whether or not it really needed to be re-installed. That was fixed this afternoon. (sync, emerge, enjoy) > > - Minor issues: > + `find` printed out lines about non-existing directories a few times. Could > you 2> /dev/null this output (in stable versions at least)? Already done in svn, just not ready for it to be live. > + Printing an empty line between the different steps the script performs would > be nice. See what I can do :) (not waffling, just need time)
> Do you know what package provided it? Sure. `USE=perl emerge net-analyzer/net-snmp`. Seems we have a clash here. :) >Funny, isn't this enough: >for file in $(find $DIR -iname "*.pm" -type f|grep -v "${PERL_VERSION}"); do >(ie, we already do that) I did not look at the code. If you look at the tree above, DB_File.pm has been installed and I ran `qpkg -f` on it, which listed the ebuild - so it was stored. >everything to do with it being missinstalled It can always happen (no one of us is perfect) that something gets installed in a broken way. It would be just great, if the perl-cleaner script would try to throw light on stale files. >See what I can do :) (not waffling, just need time) Yesterday, please. ;D Nah, thank you for working on it. My todo list isn't short either and the day should have 30 hours at least.
Mass re-assign.
Reopen if this bug is still relevant w/ app-admin/perl-cleaner-1.04.3
Next time I'll come to test this is with the next perl stable upgrade. Not bug wranglers job to resolve such bugs.
(In reply to comment #10) > Next time I'll come to test this is with the next perl stable upgrade. Not bug > wranglers job to resolve such bugs. > but your report is slightly bogus to begin with. anything under /usr/lib/perl5/<version>/<arch>-linux is there because it was part of the core perl install - perl-cleaner isn't going to touch that. nothing that is maintained by the perl herd should be going into site_perl - we put everything under vendor, including the install of dev-perl/Net-SNMP. So no offense carlo, but I do think this bug report should be closed :) /usr/lib64/perl5/vendor_perl/5.8.8/Net/SNMP/Transport/TCP6.pm /usr/lib64/perl5/vendor_perl/5.8.8/Net/SNMP/Transport/UDP.pm etc.
Closing per the above comment.
