This one is hard to explain but I'll try my best. I added icedtea-bin:8 and icedtea:8 entries to virtual/jdk:1.8 with the intention of adding the ebuilds later. Even though they were placed above oracle-jdk-bin:1.8, I didn't expect the fact they were missing from the tree to change existing behaviour. If oracle-jdk-bin is not masked then everything is fine but it is masked by default because of ACCEPT_LICENSE="* -@EULA". This causes Portage to complain about the missing ebuild instead of suggesting a license change against oracle-jdk-bin. That does not make sense to me. The end user cannot do anything about the missing ebuild while a license change is obviously their responsibility. I thought that putting oracle-jdk-bin:1.8 at the top of the list would remedy this in the short term but it didn't. It still complains about the missing ebuild, which makes even less sense. I then added ebuilds for icedtea:8 with KEYWORDS="" and icedtea-bin:8 with KEYWORDS="-* ~ppc64". In an amd64 chroot with icedtea:6 and icedtea:7 installed (no icedtea-bin, no oracle-jdk-bin, no icedtea:8), the output changed from a missing package error to a keyword change suggestion. Once again, I feel this priority is inappropriate and a license change should have been suggested but here's the really weird thing. If I remove icedtea entirely from that chroot first, the output changes again to the license change suggestion I wanted in the first place. This happens even though the icedtea SLOT given in the virtual is different to the ones that are already installed! This even holds true if you give --emptytree. Regardless of whether you think ACCEPT_LICENSE should be given a higher priority, this inconsistent behaviour is surely a bug. This has been observed with Portage 2.2.27. Note that I will be working on the packages mentioned so don't rely too much on the state of the tree when investigating this.
(In reply to James Le Cuirot from comment #0) > This causes Portage to complain about the missing ebuild instead of > suggesting a license change against oracle-jdk-bin. That does not make sense > to me. The end user cannot do anything about the missing ebuild while a > license change is obviously their responsibility. That's bug 327177.
(In reply to Zac Medico from comment #1) > (In reply to James Le Cuirot from comment #0) > > This causes Portage to complain about the missing ebuild instead of > > suggesting a license change against oracle-jdk-bin. That does not make sense > > to me. The end user cannot do anything about the missing ebuild while a > > license change is obviously their responsibility. > > That's bug 327177. Ah yes, good thing I didn't file a separate one for that then. It's quite old... :(
