Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 24876 - emerge --udpate says perl-5.8.0-r12 blocks some packages
Summary: emerge --udpate says perl-5.8.0-r12 blocks some packages
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 25276 25298 25353 25356 26853 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-07-20 05:11 UTC by Stefan Sarzio
Modified: 2003-09-25 23:09 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Sarzio 2003-07-20 05:11:47 UTC
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.
Comment 1 Stefan Sarzio 2003-07-20 06:15:21 UTC
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.
Comment 2 Jeff Ames 2003-07-20 10:42:00 UTC
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?
Comment 3 SpanKY gentoo-dev 2003-07-20 11:39:14 UTC
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 
Comment 4 Stefan Sarzio 2003-07-21 01:47:56 UTC
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.
Comment 5 Robert Coie (RETIRED) gentoo-dev 2003-07-24 13:36:53 UTC
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.
Comment 6 SpanKY gentoo-dev 2003-07-25 15:29:59 UTC
*** Bug 25276 has been marked as a duplicate of this bug. ***
Comment 7 SpanKY gentoo-dev 2003-07-25 22:24:46 UTC
*** Bug 25298 has been marked as a duplicate of this bug. ***
Comment 8 Andrew Dacey 2003-07-26 10:45:26 UTC
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.
Comment 9 Robert Coie (RETIRED) gentoo-dev 2003-07-26 11:39:30 UTC
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.
Comment 10 Andrew Dacey 2003-07-26 19:19:21 UTC
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.
Comment 11 SpanKY gentoo-dev 2003-07-27 01:27:10 UTC
*** Bug 25353 has been marked as a duplicate of this bug. ***
Comment 12 Zhen Lin 2003-07-27 02:30:51 UTC
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?'
Comment 13 Andrew Dacey 2003-07-27 07:58:17 UTC
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.
Comment 14 SpanKY gentoo-dev 2003-07-27 11:29:15 UTC
*** Bug 25356 has been marked as a duplicate of this bug. ***
Comment 15 Martin Holzer (RETIRED) gentoo-dev 2003-07-30 04:30:21 UTC
emerge -O fixes this
Comment 16 SpanKY gentoo-dev 2003-08-18 06:16:06 UTC
the man page for emerge explaings [ebuild B]
Comment 17 SpanKY gentoo-dev 2003-08-18 06:17:31 UTC
*** Bug 26853 has been marked as a duplicate of this bug. ***
Comment 18 Jeld The Dark Elf 2003-08-20 21:43:40 UTC
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.
Comment 19 Marius Mauch (RETIRED) gentoo-dev 2003-09-20 04:34:05 UTC
No, perl-5.8.0-r12 block versions *below* the ones that portage wants to install.
Comment 20 Marius Mauch (RETIRED) gentoo-dev 2003-09-25 23:09:29 UTC
No more input, closing now. IMO the perl blocker situation is/was rather
unique and already solved for approx. 98% of all users.