emerge --update perl -p These are the packages that I would merge, in order: Calculating dependencies ...done! [blocks B ] <dev-perl/ExtUtils-MakeMaker-6.05-r6 (from pkg dev-lang/perl-5.8.0-r12) [blocks B ] <dev-perl/Test-Simple-0.47-r1 (from pkg dev-lang/perl-5.8.0-r12) [blocks B ] <dev-perl/File-Spec-0.84-r1 (from pkg dev-lang/perl-5.8.0-r12) [ebuild U ] sys-apps/portage-2.0.48-r5 [2.0.48-r4] *** Portage will stop merging at this point and reload itself, recalculate dependencies, and complete the merge. [ebuild U ] dev-lang/perl-5.8.0-r12 [5.8.0-r11] Reproducible: Always Steps to Reproduce: 1.emerge --update perl 2. 3. Actual Results: s. Details Expected Results: perl get's updated unmerging those packages, emerge-update-ing perl and re-emerging those packages works! Same on another computer.
Maybe related to portage-2.0.48-r5?!? I'm not sure, but it seems on yet another computer that problem showed only after I updated portage to the new version.
perl-5.8.0-r12.ebuild specifically blocks older versions of these three packages. If you have the later versions installed, perl should be happy. However, I'd raise another question. The new versions of all three of these depend on perl-5.8.0-r12. Do they really need to do this? Then to resolve this blocking problem, instead of simply updating these three, you have to either uninstall and reinstall them, or update them with --nodeps. And if they really should depend on -r12, will updating these three with --nodeps and then updating perl break things?
you have to unmerge those 3 packages first because otherwise it'll break your perl installation further on those 3 packages have been integrated back into perl so they are no longer needed
Then why can I re-emerge those packages without the blocking?? I think this is a bug if it is only blocked when they are only blocked when you want to update perl, but not when you re-emerge them. In addition to that one of the three packages - unfortunately I don'nt know which - was re-emerged automatically.
Make sure of the versions. The blocks are on versions earlier than safe versions. The safe versions are ExtUtils-MakeMaker-6.05-r6, File-Spec-0.84-r1, and Test-Simple-0.47-r1. Those versions depend on >=perl-5.8.0-r12 because they install into directories that are not supported in earlier versions of the perl ebuild, so if you attempt to use them with older Perls, the modules will appear not to be installed.
*** Bug 25276 has been marked as a duplicate of this bug. ***
*** Bug 25298 has been marked as a duplicate of this bug. ***
The problem as I see it is you have a circular dependency. Here's the related deps for perl 5.8.0-r12: !<dev-perl/ExtUtils-MakeMaker-6.05-r6 !<dev-perl/File-Spec-0.84-r1 !<dev-perl/Test-Simple-0.47-r1" Now let's look at the deps for each of those packages. ExtUtils-MakeMaker-6.05-r6: DEPEND=">=dev-lang/perl-5.8.0-r12 >=sys-apps/sed-4" File-Spec-0.84-r1: newdepend ">=dev-lang/perl-5.8.0-r12" Test-Simple-0.47-r1: newdepend ">=perl-5.8.0-r12 >=dev-perl/Test-Harness-1.23" So what we see here is that perl-5.8.0-r12 depends on these newer versions of those 3 packages but those 3 packages each depend on perl-5.8.0-r12. So it's impossible to do an update. It seems silly to have to unmerge those 3 packages and then reinstall them. I think this should be regarded as either a bug in the ebuilds for either the 3 packages or perl-5.0.8-r12 or a bug in the portage system.
It is not a circular dependency. The block depends (the ones that start with !) say "I cannot coexist with these packages". perl-5.8.0-r12 itself does not depend on any external module packages. It is perfectly happy if no ExtUtils-MakeMaker, no File-Spec, and no Test-Simple is on your system at all. If, however, you find a need to install these packages, you must use the specific versions that are compatible with the -r12 perl. These install into the vendor directories instead of overwriting files in the core perl distribution. They depend on having perl 5.8.0-r12 or later installed, because otherwise they will not be picked up properly and will not take effect, because the standard perl @INC path does not allow the vendor directory to overrule the core.
Okay, fair enough, but I still consider that to be a bug (albeit in portage then, not these specific ebuilds). Portage should be able to resolve this kind of conflict. The only time I would expect to encounter this type of error would be if there was an unresolvable conflict (such as all the packages that would resolve the conflict being masked). There are unmasked newer packages available which would resolve the conflict here. It would be really nice if Portage were smart enough to remove the conflicting packages, install perl then install the newer versions of those packages.
*** Bug 25353 has been marked as a duplicate of this bug. ***
Blocker is blocker. Imagine, if portage automatically resolved blockers for you, when you emerge -u glibc, winex and winex-cvs get unmerged without asking? Perhaps we should append an entry to the FAQ, what does '[ebuild B] mean?'
Yes, unmerging without asking would be bad. However, I'm suggesting that if (and only if) there is a newer version of the blocker which resolves the conflict and which is not masked (either in the portage mask or by accept keywords) then to unmerge the blockers, merge the blocked package (perl in this example), then merge the newer version of the blockers. Yes, you do end up with losing the blockers for the period of time it takes to compile the blocked package and the blockers, but it would resolved the conflict without any extra intervention from the user. Perhaps though the best way to handle this in order to satisfy everyone would be to have an option in make.conf for how you want to handle this problem (with options for auto-resolve, prompt, and never resolve). That way everyone is happy.
*** Bug 25356 has been marked as a duplicate of this bug. ***
emerge -O fixes this
the man page for emerge explaings [ebuild B]
*** Bug 26853 has been marked as a duplicate of this bug. ***
Hmmm... looks like this bug is actually in portage. Here is my situation: 1. Just installed fresh gentoo. 2. Perl was merged as part of the system 3. Merged a few packages ( xfree, gnome etc. ) 4. emerge sync 5. emerge -pu --deep world Results: These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild U ] app-shells/bash-2.05b-r7 [2.05b-r6] +nls -build [ebuild U ] net-mail/mailbase-0.00-r6 [0.00-r5] [ebuild U ] net-mail/ssmtp-2.60.3 [2.48] +ssl -ipv6 -md5sum [ebuild N ] dev-perl/File-Spec-0.84-r1 [ebuild N ] dev-perl/Test-Harness-2.30 [ebuild N ] dev-perl/Test-Simple-0.47-r1 6. find /var/db/pkg/ -name \*.ebuild -exec grep -l File-Spec {} \; Results: /var/db/pkg/dev-lang/perl-5.8.0-r12/perl-5.8.0-r12.ebuild 7. grep File-Spec /var/db/pkg/dev-lang/perl-5.8.0-r12/perl-5.8.0-r12.ebuild Results: !<dev-perl/File-Spec-0.84-r1 8. qpkg -I File-Spec Results: None ( not installed ) So, IIUC emerge wants to merge these packages even though they are not currently installed and one of the installed packages ( perl ) explicitely blocks them. Ergo this is a bug in portage. It seems that this only happens when I use --deep switch. When I try emerge -p perl or emerge -pu world it doesn't want to merge these 3 packages.
No, perl-5.8.0-r12 block versions *below* the ones that portage wants to install.
No more input, closing now. IMO the perl blocker situation is/was rather unique and already solved for approx. 98% of all users.