Since the java eclasses use hooks (which paludis doesn't use) the hooks need to be installed into paludis' hooks system, in the java-config ebuild. This bug was discovered by myself with the help of Betelgeuse and ciaranm and Kugelfang on IRC. Just wanted to make a tracker here. Reproducible: Always Steps to Reproduce: 1. You might have to have 1.4 JDK as your system JDK I'm not sure. 2. Try paludis -i azureus Actual Results: It will fail as the build.xml was not re-written after src_unpack and so the source 1.5 option was not used. Expected Results: It should have built.
More to the point, defining of pre_* functions in eclasses isn't guaranteed to work, and shouldn't be relied upon by anything in the tree. If you can find a better solution please do, otherwise we'll need to talk about standardising those functions, which at this point I'd prefer not to.
(In reply to comment #1) > More to the point, defining of pre_* functions in eclasses isn't guaranteed to > work, and shouldn't be relied upon by anything in the tree. If you can find a > better solution please do, otherwise we'll need to talk about standardising > those functions, which at this point I'd prefer not to. > How are they 'not gauranteed to work' ? Even if the user over-rides them the eclass is sourced after the bashrc so you'd have to over-ride the function manually in the ebuild to break anything.
(In reply to comment #1) > More to the point, defining of pre_* functions in eclasses isn't guaranteed to > work, and shouldn't be relied upon by anything in the tree. If you can find a > better solution please do, otherwise we'll need to talk about standardising > those functions, which at this point I'd prefer not to. Mmm, we support them in trunk/. They're just really really stupid because they don't stack.
I put the following in an ebuild_unpack_post hook #!/bin/bash java-ant_bsfix [[ "${JAVA_ANT_IGNORE_SYSTEM_CLASSES}" ]] && java-ant_ignore-system-classes "${S}/build.xml" and azureus compiled succesfully but with some warnings: /usr/portage/eclass/java-ant-2.eclass: line 213: vecho: command not found /usr/libexec/paludis/ebuild.bash@1169488143: [WARNING.EBUILD] Hook '/usr/share/paludis/hooks/ebuild_unpack_post/ant/usr/portage/eclass/java-ant-2.eclass: .bash' returned failure (from /usr/portage/net-p2p/azureus/azureus-2.5.0.2.ebuild)
(In reply to comment #2) > How are they 'not gauranteed to work' ? > > Even if the user over-rides them the eclass is sourced after the bashrc so > you'd have to over-ride the function manually in the ebuild to break anything. > Show me the discussion on -dev that says "these hooks are now available to use".
(In reply to comment #5) > (In reply to comment #2) > > How are they 'not gauranteed to work' ? > > > > Even if the user over-rides them the eclass is sourced after the bashrc so > > you'd have to over-ride the function manually in the ebuild to break anything. > > > > Show me the discussion on -dev that says "these hooks are now available to > use". > How about adding java to CC and we could have explained this once more. The hooks were added because they were a good solution to the problem at hand. This was blessed by the portage team (zmedico?) at that time. I wonder why no-one complained about the hooks when we asked about our eclasses on gentoo-dev... It could be possible to do this thing without the hooks so we can look into that too. I think no-one will take up the task of adding rewriting to all of our src_unpack functions either.
(In reply to comment #6) > How about adding java to CC and we could have explained this once more. The > hooks were added because they were a good solution to the problem at hand. This > was blessed by the portage team (zmedico?) at that time. I wonder why no-one > complained about the hooks when we asked about our eclasses on gentoo-dev... It > could be possible to do this thing without the hooks so we can look into that > too. I think no-one will take up the task of adding rewriting to all of our > src_unpack functions either. They're a horrible solution. They don't stack and they override something that is used by users. What's going to happen if anyone else starts using the same functions?
(In reply to comment #7) > > They're a horrible solution. They don't stack and they override something that > is used by users. What's going to happen if anyone else starts using the same > functions? > Yeah I know, that's why we are the only allowed to use them in the eclasses. We can get rid of the hooks when Portage does proper environment saving in stable. I think that is coming with 2.1.2, isn't it?
Reopening for the java team to take care of.
(In reply to comment #8) > Yeah I know, that's why we are the only allowed to use them in the eclasses. We > can get rid of the hooks when Portage does proper environment saving in stable. > I think that is coming with 2.1.2, isn't it? I think you're talking about bug 51370 which has been fixed since 2.1.1 and is stable.
(In reply to comment #10) > (In reply to comment #8) > > Yeah I know, that's why we are the only allowed to use them in the eclasses. We > > can get rid of the hooks when Portage does proper environment saving in stable. > > I think that is coming with 2.1.2, isn't it? > > I think you're talking about bug 51370 which has been fixed since 2.1.1 and is > stable. Haven't poked at the rev to verify it, but as long as it protects the required java vars, would address it. (In reply to comment #7) > (In reply to comment #6) > They're a horrible solution. They don't stack and they override something that > is used by users. What's going to happen if anyone else starts using the same > functions? It's primarily a user feature, introduced due to the usefulness of /etc/portage/bashrc breaking down with proper env state handling. Reason for java using it is two fold; 1) java 1.4/1.5 (don't recall which) migration *requires* proper env handling, namely protection of the ebuild env from bug 51370 2) it works in the interim, saving mass ebuild changes for what is fundamentally an env handling issue. Short version; it's valid- I specifically gave them the go ahead till the underlying issues (not their fault) were fixed. If paludis doesn't want to support (pre|post)_*, whatever, long term it was only a user feature. Short term, it's part of the required env support.
Renaming because paludis 0.16.0 supports portage's phase hooks so the idea of java-config installing paludis-specific hooks is moot. In the longer term, I would still like to stop using them if possible. What it IMHO requires: * verify that bug 51370 is really fixed in stable portage version and dep on it (or whatever virtual there will be sufficient for this, now there's none) * ensure that the java-pkg{-opt}_pkg_setup is called wherever overriden in the ebuild (or other inherited eclass, especially for the -opt packages), again like in gen-1 * move build.xml rewriting from post_src_unpack() - eant() looks like the best place and doesn't require us to rewrite all ebuilds In the end it shouldn't be mass ebuild changes, but we need to be careful.
Seems portage does not handle vars correctly atm: * post_pkg_setup * GENTOO_VM=sun-jdk-1.4 * pre_src_unpack * GENTOO_VM gets lost in between. Will see if I can find a Portage bug to reopen.
It's not lost completely, "just" not exported. diff -u -B -r1.20 java-pkg-2.eclass --- java-pkg-2.eclass 28 Jan 2007 21:42:24 -0000 1.20 +++ java-pkg-2.eclass 16 Mar 2007 00:11:32 -0000 @@ -102,6 +102,7 @@ } pre_src_unpack() { + echo GENTOO_VM=$GENTOO_VM java-config -f java-pkg-2_pkg_setup } ebuild somejavaebuild.ebuild unpack results in: GENTOO_VM=sun-jdk-1.4 sun-jdk-1.6.0.1 * Using: sun-jdk-1.4 That's bad, we need it exported :/
(In reply to comment #14) > That's bad, we need it exported :/ Portage is fixed in svn r6213 to preserve the export attribute. We can have it in the next release of the 2.1.2 branch (too bad this problem wasn't mentioned sooner since 2.1.2.2 was stabled just last week).
(In reply to comment #15) > (In reply to comment #14) > > That's bad, we need it exported :/ > > Portage is fixed in svn r6213 to preserve the export attribute. We can have it > in the next release of the 2.1.2 branch (too bad this problem wasn't mentioned > sooner since 2.1.2.2 was stabled just last week). > It wasn't mentioned because we were assured that it works and only now got the time to start testing removing the hooks. I also didn't find this problem until I tried to emerge something that really needs the switching like dev-java/batik.
I've just released portage-2.1.2.3 and it has support for preservation of export attributes.
(In reply to comment #17) > I've just released portage-2.1.2.3 and it has support for preservation of > export attributes. > Seems to work without the hooks now.
All relevant arches stabilized 2.1.2.7
Created attachment 126747 [details, diff] no-hooks.patch Here is the eclass patch for removing the hooks.
(In reply to comment #20) > Created an attachment (id=126747) [edit] > no-hooks.patch > > Here is the eclass patch for removing the hooks. > Arches please test this patch before I release it (goes straight to stable users). I have been running my desktop for months with it so should be good to go.
I emerged about 50 java packages and tested the ones I could do in a simple way. So x86 is out of here.
(In reply to comment #22) > I emerged about 50 java packages and tested the ones I could do in a simple > way. So x86 is out of here. > Hooks removed.
