problems since last portage update

MQube2 · n00b Joined: 05 Dec 2002 Posts: 3

Hi all,

i would be very glad if someone could give me an explanation what's going on here. Since the last update to portage-2.0.46-r12 i have a problem with 'emerge -up world --deep'. It boils out with an error that states that all ebuilds that could satisfy >=virtual/jdk-1.4 are masked out. This dependency is required by dev-java/sun-j2sdk-1.4.0-r1 which i have installed to get the java plugin for mozilla. But i have dev-java/sun-jdk-1.4.1.01-r1 installed, which is in no way masked and provides virtual/jdk-1.4. If i type in ACCEPT_KEYWORDS=~x86 in front of the emerge command the error does not appear. Furthermore since today an 'emerge -up world' wants to downgrade my hpijs to version 1.2.2 from 1.3 although i have an 1.3 ebuild (with x86 instead of ~x86) in my PORTDIR_OVERLAY directory and observed no problems so far. Maybe i do not see the point here but maybe something is wrong with my portage. Any hint is very much appreciated. Thanks in advance.

MQube2 · n00b Joined: 05 Dec 2002 Posts: 3

Second problem is gone after update to portage-2.0.47-r2. Must have been some invalid entry in the dependency cache although i have no idea how this could happen. First problem persists, must be something similar to this one:
https://forums.gentoo.org/viewtopic.php?t=29278
Only difference is that in my case it happens with the --deep option.

MQube2 · n00b Joined: 05 Dec 2002 Posts: 3

Since the portage update to version 2.0.47-r2 obviously has been taken back the problem with downgrading my hpijs to 1.2.2 appeared again after portage-2.0.46-r12 was back on my system. The solution was indeed very simple after i found out where to look. The hpijs ebuild on the portage tree has been updated to a newer version 1.2, the one from my portage overlay directory was version 1.1. This could be seen in the cvs header in the ebuild file. After copying the new version 1.3 to the portage overlay directory and replacing the ~x86 with x86 everything worked as expected again. Maybe the problem was not about the cvs version numbers but about the newer timestamp of the original ebuild file, i don't know. Those kind of dependencies are rather curious IMHO.