[ebuild U ] dev-db/mariadb-10.0.29:0/18::gentoo [10.0.19:0/0::gentoo] [...] [ebuild U ~] virtual/mysql-5.6-r9:0/18::gentoo [5.6-r2:0/18::gentoo] [...] [blocks B ] <virtual/mysql-5.6-r4 ("<virtual/mysql-5.6-r4" is blocking dev-db/mariadb-10.0.29) Conflict: 9 blocks (1 unsatisfied) Reproducible: Always Actual Results: Bug exists for over 15 years now. Expected Results: Bug should have been fixed a looooooooooooooooooooooooooooooong time ago. Fix it. NOW! No new features until this one is resolved once and for all.
What version of sys-apps/portage do you have? It works for me with portage-2.3.6, where [blocks b] indicates that the blocker has been automatically resolved via the virtual/mysql upgrade: $ emerge -puv mariadb virtual/mysql These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] dev-db/mariadb-10.0.30:0/18::gentoo [10.0.19:0/0::gentoo] [ebuild U ] virtual/mysql-5.6-r6:0/18::gentoo [5.6-r2:0/18::gentoo] [blocks b ] <virtual/mysql-5.6-r4 ("<virtual/mysql-5.6-r4" is blocking dev-db/mariadb-10.0.30)
(In reply to Bodo Thiesen from comment #0) > Fix it. > > NOW! > > No new features until this one is resolved once and for all. This is an unacceptable tone on a bug tracker, let alone one staffed primarily by volunteers. That said, your excerpt indicates that you are mixing ~arch and arch, which is done at one's own risk. Add actionable information (full unedited command output, emerge --info) if you expect action to be taken.
This bug should have been assigned to the MySQL team and not to portage team. Also, as already stated in the prior comment, this is an unacceptable tone. Worse, this is almost certainly an invalid bug.
Created attachment 473812 [details] See attachment #1 [details]
Created attachment 473814 [details] Attachment #2 [details]
1. My tone was off, I sincerely want to apologize for this. 2. The reason for my tone being off was, that almost each time I try to install/upgrade anything, I get some blockers like this or others and I didn't notice a change to this behavior since Gentoo exists. Problems like this are regularly reported again and again and many times just adding some packages to the command line resolves conflicts, sometimes forcing the merge with -O just makes the problem go away with no problems, like here, where I -O'ed virtual/mysql following a -1 dev-db/mariadb. And all of those conflict problems for 15 years add up. 3. I am not sure, which portage version I used. I synced the tree and upgraded portage, I don't remember whether it was before of after reporting this bug. So, let's just assume, it was after and the report was against an older version. Either way, this is my state (including the way to reach it - now everything with portage 2.3.5): See attachment #1 [details] After that, two hickups happened (c++11) but the rest worked. So, next building place, c++11. See attachment #2 [details] Maybe, I made my point of frustration about portage a little more clear now. I'm not going to resolve those now, but you can guess, how long it will take until I can actually hit "yes" and get the packages upgraded ... But the point is, that most of the things I do here to resolve the problems and figure out dependencies is the job of portage. 4. About mixing arch and ~arch: The problems stated here are dependency resolving problems, many of them being either bogus or being able to be solved manually by just adding the right[TM] packages to the command line and all of them also happening without arch and ~arch mixing at all. The first example proves it, where I just added more and more packages to the command line until portage found a solution. Also, it's kinda hard to not mix arch and ~arch when trying to run stable packaged but needing packages like icedtea for java 8 with 3.3.0 being the only dev-java/icedtea version to provide that and being ~arch. 5. I hope, the tone of this comment is fine and again, I sincerely want to apologize for my tone in the initial report.
Oh, please ignore the links to https://bugs.gentoo.org/attachment.cgi?id=1 and https://bugs.gentoo.org/attachment.cgi?id=2, I didn't know this bug tracker interprets the comments in that way, only attachments https://bugs.gentoo.org/attachment.cgi?id=473812 and https://bugs.gentoo.org/attachment.cgi?id=473814 are relevant here.
(In reply to Bodo Thiesen from comment #6) > Maybe, I made my point of frustration about portage a little more clear now. > I'm not going to resolve those now, but you can guess, how long it will take > until I can actually hit "yes" and get the packages upgraded ... In the latest portage release, we've increased the default --backtrack setting (bug 540562) in order to help solves issues like this. Also, there have been many recent fixes involving slot operator rebuilds (like bug 614390, bug 612846, bug 612772, bug 612094, and bug 612042. Also see the "What should I do when emerge reports a lot of dependency conflicts involving built slot-operator (foo/bar:X/Y=) dependencies?" part of the FAQ: 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 I always try with --ignore-built-slot-operator-deps=y first, since dealing with built slot operator deps is a waste of time when the configuration is not solvable with --ignore-built-slot-operator-deps=y.
This is also relevant: https://wiki.gentoo.org/wiki/Project:Portage/FAQ#Why_is_there_a_dependency_conflict_whey_I_attempt_to_upgrade_a_single_package.3F
I didn't even consider using --ignore-built-slot-operator-deps=y because the man page defines this to be a debugging feature. Anyway: It prevents some spam but conflicts that aren't solves without it, won't be solved with it either - at least from my experience in the last few weeks. Anyway: I like to recommend adding some hint to those two strategies on this kind of dependency conflicts (like portage hinting to increasing --backtrack). Besides of that, I close this bug now, I didn't experience this exact bug any more so, let's call it invalid.
(In reply to Bodo Thiesen from comment #10) > I didn't even consider using --ignore-built-slot-operator-deps=y because the > man page defines this to be a debugging feature. Anyway: It prevents some > spam but conflicts that aren't solves without it, won't be solved with it > either - at least from my experience in the last few weeks. > > Anyway: I like to recommend adding some hint to those two strategies on this > kind of dependency conflicts (like portage hinting to increasing > --backtrack). Thanks, I've added a note in bug 598503, commend #4.
