Summary: | sys-apps/portage: random virtual selection, triggered by || ( =virtual/jdk-1.7* =virtual/jdk-1.8* ) in scala deps | ||
---|---|---|---|
Product: | Portage Development | Reporter: | octoploid <octoploid> |
Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | esigra, java, jstein |
Priority: | Normal | Keywords: | InVCS |
Version: | 2.2 | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=600346 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 155723, 604854 | ||
Attachments: |
jdk-1.7 debug log (portage-2.3.2)
jdk-1.8 debug log (portage-2.3.2) |
Description
octoploid
2016-10-22 07:50:55 UTC
I haven't seen this random behaviour before but I do know that Portage usually picks virtual/jdk-1.7 over virtual/jdk-1.8 simply because the underlying icedtea(-bin) version is newer for 1.7. This is due to a change in the icedtea versioning scheme. This is contrary to what you would expect and we probably would have taken a different approach had we known this would cause so much trouble. Strangely I don't think we've had a bug report filed about it yet. I consider this to be a Portage bug so I'm reassigning it but I suspect it won't be fixed by the time we remove Java 7, which is on the current agenda. This random behavior is interesting behavior. I suspect that having =virtual/jdk-1.7* to the left of =virtual/jdk-1.8* in the scala dependencies may help to trigger the buggy portage behavior: || ( =virtual/jdk-1.7* =virtual/jdk-1.8* ) Generally, preferred versions should be on the left. Anyway, we should certainly fix portage to handle this better. I can reproduce this very reliably. The probability of either outcome seems to be 50%. Created attachment 451955 [details]
jdk-1.7 debug log (portage-2.3.2)
Created attachment 451957 [details]
jdk-1.8 debug log (portage-2.3.2)
(In reply to Zac Medico from comment #4) > Created attachment 451955 [details] > jdk-1.7 debug log (portage-2.3.2) The problem occurs when processing the ant-core dependencies: Parent: (dev-java/ant-core-1.9.2:0/0::gentoo, ebuild scheduled for merge) Depstring: || ( >=virtual/jdk-1.5 dev-java/gcj-jdk ) I'm able to trigger the problem 100% of the time when I emerge ant-core in a stage3. I've isolated the incorrect behavior to a problem in the construction of the _dep_choice.cp_map dictionary inside the dep_zapdeps function, with this input: ['||', ['dev-java/icedtea-bin:8', '=virtual/jdk-1.8.0-r3', '>=virtual/jdk-1.5'], ['dev-java/icedtea-bin:7', '=virtual/jdk-1.7.0-r2', '>=virtual/jdk-1.5']] The cp_map dictionaries end up as follows: For virtual/jdk-1.8.0-r3: {'dev-java/icedtea-bin': <Package ('ebuild', '/', 'dev-java/icedtea-bin-3.1.0', 'merge', 'gentoo')>, 'virtual/jdk': <Package ('ebuild', '/', 'virtual/jdk-1.8.0-r3', 'merge', 'gentoo')>} For virtual/jdk-1.7.0-r2: {'dev-java/icedtea-bin': <Package ('ebuild', '/', 'dev-java/icedtea-bin-7.2.6.7', 'merge', 'gentoo')>, 'virtual/jdk': <Package ('ebuild', '/', 'virtual/jdk-1.8.0-r3', 'merge', 'gentoo')>} The cp_map for virtual/jdk-1.7.0-r2 erroneously contains virtual/jdk-1.8.0-r3 because that's the highest virtual/jdk matched by the '>=virtual/jdk-1.5' atom. When the versions are compared, the virtual/jdk-1.7.0-r2 cp_map appears to be the best choice because: * it has a higher version of dev-java/icedtea-bin (7.2.6.7 is higher than 3.1.0) * the version of virtual/jdk has erroneously been set to virtual/jdk-1.8.0-r3 (In reply to Zac Medico from comment #2) > This random behavior is interesting behavior. I suspect that having > =virtual/jdk-1.7* to the left of =virtual/jdk-1.8* in the scala dependencies > may help to trigger the buggy portage behavior: > > || ( =virtual/jdk-1.7* =virtual/jdk-1.8* ) > > Generally, preferred versions should be on the left. Anyway, we should > certainly fix portage to handle this better. It turns out that the ordering is significant because dev-java/icedtea-bin:8 has a lower version than dev-java/icedtea-bin:7. This reverse version ordering defeat's portage's automatic re-ordering, so it's very important to put =virtual/jdk-1.8* on the left side. I've posted this patch for review: https://archives.gentoo.org/gentoo-portage-dev/message/8026baee76ff2fd8be8c9face5467793 https://github.com/gentoo/portage/pull/65 (In reply to Zac Medico from comment #8) > It turns out that the ordering is significant because dev-java/icedtea-bin:8 > has a lower version than dev-java/icedtea-bin:7. This reverse version > ordering defeat's portage's automatic re-ordering, so it's very important to > put =virtual/jdk-1.8* on the left side. That sounds like a bug worth reporting. I'm pretty sure it will confuse the hell out of paludis which assumes versions grow monotonically. (In reply to Michał Górny from comment #10) > (In reply to Zac Medico from comment #8) > > It turns out that the ordering is significant because dev-java/icedtea-bin:8 > > has a lower version than dev-java/icedtea-bin:7. This reverse version > > ordering defeat's portage's automatic re-ordering, so it's very important to > > put =virtual/jdk-1.8* on the left side. > > That sounds like a bug worth reporting. I'm pretty sure it will confuse the > hell out of paludis which assumes versions grow monotonically. Maybe rename the icedtea 7 packages to dev-java/icedtea7 and dev-java/icedtea7-bin for the remainder of their lives. (In reply to Zac Medico from comment #9) > I've posted this patch for review: > > https://archives.gentoo.org/gentoo-portage-dev/message/ > 8026baee76ff2fd8be8c9face5467793 > https://github.com/gentoo/portage/pull/65 In the master branch now: https://gitweb.gentoo.org/proj/portage.git/commit/?id=cd864267a463769cbd40e058611d2488cc15bf70 Wow, fast work, Zac! Sorry for saying we would probably remove Java 7 first, you totally proved me wrong there. :D I can't remember all the cases where I've seen this problem but ant-core was one of them and I can confirm that your fix works here. Java team doesn't really touch the Scala stuff but I have told the maintainer not to use || with the virtuals because if confuses the Java eclasses. Looks like I'll have to remind him. ;) ant-core is a special case. We don't support gcj-jdk as a general compiler so it's not in the virtuals but we need to build ant-core with it in order to bootstrap icedtea:7. This can go away soon because icedtea:8 isn't built with ant. As for the icedtea versioning mess, there seems little point in changing tack now. I want 7 gone ASAP. If Paludis fumbled it that badly, I think we would have heard about it by now. Fixed in portage-2.3.3. |