$ sudo cave resolve perl Done: 1 restarts, 2203 steps These are the actions I will take, in order: -r dev-lang/perl:0::gentoo (not the best version) 5.12.2-r6 to ::installed replacing 5.12.2-r6 berkdb -build -debug -doc gdbm -ithreads build_options: -optional_tests split strip -trace -preserve_work Reasons: target, app-admin/perl-cleaner, dev-perl/Authen-SASL, 15 more Total: 1 reinstalls I cannot proceed without being permitted to do the following: -r dev-lang/perl:0::gentoo (not the best version) 5.12.2-r6 to ::installed replacing 5.12.2-r6 berkdb -build -debug -doc gdbm -ithreads build_options: -optional_tests split strip -trace -preserve_work Reasons: target, app-admin/perl-cleaner, dev-perl/Authen-SASL, 15 more Cannot proceed without: --permit-old-version Executing pretend actions: 1 of 1 * No unread news items found $ sudo paludis -ip perl paludis@1296952870: [WARNING paludis.deprecated] In thread ID '26876': ... In program paludis -ip perl: ... paludis is deprecated. Use 'cave' instead. Building target list... Building dependency list: ... 10 steps These packages will be installed: * dev-lang/perl [U 5.12.2-r6 -> 5.12.3] <target> Reasons: app-admin/perl-cleaner-2.8:0::installed, sys-devel/libperl-5.10.1:1::installed berkdb -build -debug -doc gdbm -ithreads build_options: -optional_tests split strip -trace -preserve_work 11.49 MBytes to download Total: 1 package (1 upgrade), 11.49 MBytes to download Checking for possible errors...... * No unread news items found Once perl is upgraded with paludis, cave doesn't complain. Verified on 2 systems Reproducible: Always
Note: Problem goes away after paludis -i perl and cave resolve system -ex. cave resolve world -c still show the issue after paludis -i perl until cave resolve system -ex is run. Seems like a dependency needs to be rebuilt but no indication of which one.
Had the same problem. I use mixed portage/paludis install. I could use portage to emerge perl to get to 5.12.3-r1 But i still had dependency trouble in paludis/cave after cave fix-linkage and running perl-cleaner -all After emerge virtual/perl-Sys-Syslog virtual/perl-Compress-Raw-Zlib virtual/perl-IO-Compress (I could not use cave/paludis to update them, just portage) it went fine to use "cave resolve installed-packages"
cave resolve world -c --permit-downgrade PlRPC --remove-if-dependent "*/*" -l "*/*" --purge "*/*" -x I used this kind of command to update. --permit downgrade part is unrelated to this one, and I suppos --remove-if-dependent too, and --purge too. -l (less restrictive blockers) allows the system to not remove those old virtual files and just allow them to use this new version. The reason why this happens, is that those virtual files depends on 5.12.2 OR 5.12.3. Then, you’re upgrading perl to new version and you’d need to recompile the virtual files to use this new program to be sure they actually works. -l makes this check not to work, so Gentoo’s good ebuilds works like they’ve intended.
This seems to have gotten better with recent versions of paludis. Is it possible this bug is now resolved? If I don't hear anything on this bug by Feb 14, I would like to mark it obsolete. Let me know if there is any issue with that.
No problems with perl or perl-cleaner. This is an old one.
(In reply to Harris Landgarten from comment #5) > No problems with perl or perl-cleaner. This is an old one. Thanks for the prompt reply; does that mean you're comfortable with this being resolved?
yes
Resolving as obsolete due to the age and this functionality working with recent versions of paludis. If this changes for any reason; please, re-open and update the information.
