DEPEND is a stacked variable, to which PMS gives no guarantee that it has a correct value in the ebuild environment (or that it is exported at all). Therefore, querying its value to enforce a specific VM is incorrect. Please fix the code not to rely on it.
Heh, well while I do like to play by the rules, you obviously have to appreciate that this approach predates PMS by some years and even the eclass itself! Out of curiosity, I traced it all the back to October 2004 in the original java-pkg.eclass. This isn't the only place that DEPEND is used but they all check it for broadly the same reason; to determine which JDK (and JRE from RDEPEND) version to use. With hindsight, we tend to rely less on magic these days but correcting this would mean changing just about every Java ebuild in the tree. We can try to deal with this going forwards but if you think I'm going to fix every old ebuild, forget it. We also have to consider the state of play, which is that I'd actually like to chuck a lot of this stuff on the bonfire anyway. Unfortunately our next generation has been stuck in the ideas phase for a while now. I did check PMS to see what you are referring to but I couldn't find it. Please point me in the right direction.
I'm sorry but I don't remember the exact bits. ulm? But I think the main idea is that the PMS does not specify those bits as guaranteed to have any valid value in the ebuild environment section, and the 'global variables' section does not apply to them since they have a defined special meaning.
(In reply to Michał Górny from comment #2) > I'm sorry but I don't remember the exact bits. ulm? DEPEND is _not_ a stacked variable, so I believe that the normal rules specified in http://dev.gentoo.org/~ulm/pms/head/pms.html#x1-12200011.2 apply to it. > [...] the 'global variables' section does not apply to them since they > have a defined special meaning. Right, there were some doubts about this. It was settled (after consulting with Ciaran about the original intention of that sentence): https://archives.gentoo.org/gentoo-pms/message/087e19bbe502fdd105bf67125a4285c8
(In reply to Ulrich Müller from comment #3) > DEPEND is _not_ a stacked variable, so I believe that the normal rules > specified in http://dev.gentoo.org/~ulm/pms/head/pms.html#x1-12200011.2 > apply to it. Strike that. Of course, *DEPEND variables are stacked (along with IUSE and REQUIRED_USE): https://projects.gentoo.org/pms/6/pms.html#x1-11700010.2
Although it should still be addressed, it may help to know that almost all packages (there are possibly ant task and mysql-related exceptions) add the Java virtuals in the ebuild itself and don't rely on other eclasses to add them. I still don't entirely understand why it is an issue though, isn't the value of DEPEND fully determined by the time any of the phase functions are called?
Because the package managers are not required to populate the ebuild environment with final values. They are free to store the values from eclasses in any way they like, and retrieve them afterwards. They need to use the combined value for metadata but they're not required to serialize it back.
