Summary: | =dev-lang/perl-5.22* conflicts with dev-lang/perl:0/5.22= | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Jeroen Roovers (RETIRED) <jer> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | kentnl |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Jeroen Roovers (RETIRED)
2016-12-31 11:06:58 UTC
(In reply to Jeroen Roovers from comment #0) > (dev-lang/perl-5.22.2:0/5.22::gentoo, installed) pulled in by These "pulled in by" messages typically display multiple packages that were pulled in, but you've only posted one of them. Was (dev-lang/perl-5.22.2:0/5.22::gentoo, installed) the only one that got pulled in? Since you haven't posted the whole emerge output, it's not clear whether it's a "slot conflict" or a "blocker conflict". Both kinds of conflicts trigger these "pulled in by" messages. (In reply to Jeroen Roovers from comment #0) > dev-lang/perl:0/5.22=[-build(-)] required by > (dev-tex/html2latex-1.1-r1:0/0::gentoo, installed) > ^^^^^^^^ > > (and 30 more with the same problems) If it's a slot conflict, you're probably going to want to use the --pretend and --ignore-built-slot-operator-deps=y suggestion here: https://wiki.gentoo.org/wiki/Project:Portage/FAQ#What_should_I_do_when_emerge_reports_a_lot_of_dependency_conflicts_involving_built_slot-operator_.28foo.2Fbar:X.2FY.3D.29_dependencies.3F 1) please try with a higher backtrack value (e.g., --backtrack=1000 ); there's already a bug to make that default. 2) useful output is missing; ideally set --verbose-conflicts=y Is there any way =dev-lang/perl-5.22* does not or should not resolve to dev-lang/perl:0/5.22= ? I filed this bug report because if after dependency resolution, portage arrives at "=dev-lang/perl-5.22* conflicts with dev-lang/perl:0/5.22", then it is doing it wrong. (In reply to Jeroen Roovers from comment #4) > Is there any way =dev-lang/perl-5.22* does not or should not resolve to > dev-lang/perl:0/5.22= ? No, because all of the per-5.22* ebuilds set SLOT="0/5.22". > I filed this bug report because if after dependency resolution, portage > arrives at "=dev-lang/perl-5.22* conflicts with dev-lang/perl:0/5.22", then > it is doing it wrong. I think that you have misinterpreted the output. The message posted in comment #0 indicates that both =dev-lang/perl-5.22* and dev-lang/perl:0/5.22=[-build(-)] match (dev-lang/perl-5.22.2:0/5.22::gentoo, installed), so it doesn't mean what you thought. (In reply to Zac Medico from comment #5) > (In reply to Jeroen Roovers from comment #4) > > Is there any way =dev-lang/perl-5.22* does not or should not resolve to > > dev-lang/perl:0/5.22= ? > > No, because all of the per-5.22* ebuilds set SLOT="0/5.22". > > > I filed this bug report because if after dependency resolution, portage > > arrives at "=dev-lang/perl-5.22* conflicts with dev-lang/perl:0/5.22", then > > it is doing it wrong. > > I think that you have misinterpreted the output. The message posted in > comment #0 indicates that both =dev-lang/perl-5.22* and > dev-lang/perl:0/5.22=[-build(-)] match (dev-lang/perl-5.22.2:0/5.22::gentoo, > installed), so it doesn't mean what you thought. If this were just a matter of human interpretation I wouldn't have filed this bug report. I already tried what comment #3 suggested, to set `--backtrack=1000`, which resulted in the same output being printed after about 5 hours of churning on a single CPU while emerge was continually using half a gigabyte of RAM. To me the positions of the carets indicate that the SLOT/sub-SLOT 0/5.22= does not match the version 5.22*. I would think that any version 5.22* would match that SLOT and sub-SLOT but apparently portage can't resolve that. (Maybe I should try a newer-than-stable version? I don't know.) I may sound really stupid now, but to my limited wisdom and knowledge those should resolve to the same, hence the Summary of this bug report. I didn't expect to be met with disagreement on the statement in the Summary being false. Usually this message takes this form: PACKAGE-A pulled in by >=PACKAGE-A by THINGNEEDSPACKAGEA ^^ PACKAGE:SLOT by THINGNEEDSUBSLOT ^^^^ PACKAGE-B pulled in by PACKAGE:OTHERSLOT BY OTHERTHINGTHINGNEEDSSUBSLOT ^^^^^^^^^ In both cases, the carets don't indicate the block, they only indicate the reason for the dependency target being required. The problem is not so much the carets, but the multiple packages they infer ( A vs B ) WHAT pulled in by WHY by WHAT You've only given us the one of the alternatives portage couldn't decide between Usually that's a problem of "Things were considered in the upgrade graph that broke stuff that was in installed-but-not-a-dependency-of-world", which includes things that are exclusively bdeps. ( That is, it considers the bdeps for blocking, but not for reinstallation to resolve blocking ) Here, --with-bdeps y helps a boatload, and is very effective in conjunction with a backtrack value ( But I'm uncertain if backtracking alone is sufficient without bdeps ) Though I agree, the message is very confusing. (In reply to Jeroen Roovers from comment #6) > If this were just a matter of human interpretation I wouldn't have filed > this bug report. I'm _not_ claiming that it's _only_ a matter of interpretation, but it is at least one on the matters involved here, as explained by Kent in comment #7. > I already tried what comment #3 suggested, to set > `--backtrack=1000`, which resulted in the same output being printed after > about 5 hours of churning on a single CPU while emerge was continually using > half a gigabyte of RAM. A large --backtrack value is going to be useless if you've got a configuration issue being obscured by a bunch of conflicts involving built slot-operator deps. That's why you should try with --pretend and --ignore-built-slot-operator-deps=y as suggested in comment #2. (In reply to Kent Fredric (IRC: kent\n) from comment #7) Thanks, that's what I was trying to explain regarding "multiple packages" in comment #1. Every conflict involves at least _two_ "pulled in by" packages, so there must be at least one more besides (dev-lang/perl-5.22.2:0/5.22::gentoo, installed). Anyway, my experience has shown that --pretend and --ignore-built-slot-operator-deps=y is the best starting point for troubleshooting problems of this nature, as suggested in comment #2. The patch from bug 602964 is also likely to be helpful in many cases. |