[gentoo-dev] [PATCH] fix java-utils-2 eclass to only use DESTTREE during src_install
Currently the java-utils-2 eclass refers to $DESTTREE in the
java-pkg_init_paths_ function that gets run during pkg_setup (via the
java-pkg-2 eclass that calls java-pkg_init). The java-pkg_init_paths_
function also gets called again for most src_install java-utils-2 eclass
functions that use the related variables but the current implementation
doesn't allow the variables to be reset.
This is an issue for pkg managers that try to follow the spec and don't
define DESTTREE outside of src_install. Note that DESTTREE was recently
added to pms so you'll probably have to view the live version to see the
DESTTREE related info.
The attached patch fixes the situation by adding java-pkg_init_paths_
calls to a couple src_install related functions that use the related
variables and removes the call to it during pkg_setup (no related
variables appear to be used before src_install but I could be missing
something). People familiar with various java pkgs should test it to
make sure those variables aren't used before src_install.
Thoughts or comments welcome,
Tim
--- java-utils-2.eclass
+++ java-utils-2.eclass
@@ -192,6 +192,7 @@
[[ ${#} -lt 1 ]] && die "At least one argument needed"
java-pkg_check-phase install
+ java-pkg_init_paths_
local dest=/usr/share/doc/${PF}/examples
if [[ ${1} == --subdir ]]; then
@@ -543,6 +544,7 @@
# QA checks
java-pkg_check-phase install
+ java-pkg_init_paths_
[[ -z "${dir}" ]] && die "Must specify a directory!"
[[ ! -d "${dir}" ]] && die "${dir} does not exist, or isn't a directory!"
@@ -2060,7 +2062,6 @@
java-pkg_announce-qa-violation "Using old ant_src_unpack. Should be src_unpack"
fi
- java-pkg_init_paths_
java-pkg_switch-vm
PATH=${JAVA_HOME}/bin:${PATH}
pgp5lx1_7XasF.pgp
Description: PGP signature
Re: [gentoo-dev] [PATCH] fix java-utils-2 eclass to only use DESTTREE during src_install
On Tue, 1 Apr 2014 15:31:56 -0700 Tim Harder wrote: > Currently the java-utils-2 eclass refers to $DESTTREE in the > java-pkg_init_paths_ function that gets run during pkg_setup (via the > java-pkg-2 eclass that calls java-pkg_init). The java-pkg_init_paths_ > function also gets called again for most src_install java-utils-2 > eclass functions that use the related variables but the current > implementation doesn't allow the variables to be reset. > > This is an issue for pkg managers that try to follow the spec and > don't define DESTTREE outside of src_install. Note that DESTTREE was > recently added to pms so you'll probably have to view the live > version to see the DESTTREE related info. > > The attached patch fixes the situation by adding java-pkg_init_paths_ > calls to a couple src_install related functions that use the related > variables and removes the call to it during pkg_setup (no related > variables appear to be used before src_install but I could be missing > something). People familiar with various java pkgs should test it to > make sure those variables aren't used before src_install. > > Thoughts or comments welcome, > Tim Tim, java-utils-2 does it like that since before PMS, since around the time Portage gained support for EAPIs. PMS leaves it open whether using DESTREE in pkg_setup is allowed or not. Neither Portage, Paludis nor earlier version of Pkgcore did mind this use. Well, one could argue that using DESTREE in pkg_setup is allowed. I would welcome PMS clearly defining the scope of DESTREE and the most logical choice of course would be src_install only where it is currently explicitly required. If we fix java-utils-2 we should fix PMS as well. After all, java-utils-2 is a prime suspect for the different handling of DESTREE and for instance INSDESTREE in PMS. This asymmetry is why I didn't touch java-utils-2 when I looked into exactly this usage of DESTREE 2+ years ago. Ralph signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] fix java-utils-2 eclass to only use DESTTREE during src_install
> On Fri, 11 Apr 2014, Ralph Sennhauser wrote: > I would welcome PMS clearly defining the scope of DESTREE and the > most logical choice of course would be src_install only where it is > currently explicitly required. This has been fixed in PMS some time ago: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=294741c5f69bec36dae2e34ba1b7dceb2cb1fd7b https://bugs.gentoo.org/show_bug.cgi?id=460512 Scope is src_install only. Ulrich pgpFMtU3W1lzY.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH] fix java-utils-2 eclass to only use DESTTREE during src_install
On 2014-04-11 09:02, Ralph Sennhauser wrote: > java-utils-2 does it like that since before PMS, since around the time > Portage gained support for EAPIs. PMS leaves it open whether using > DESTREE in pkg_setup is allowed or not. Neither Portage, Paludis nor > earlier version of Pkgcore did mind this use. Well, one could argue > that using DESTREE in pkg_setup is allowed. Pkgcore explicitly worked around it for a long time (since 0.2.12-ish) specifically noting it was for this case until I dropped it recently since keeping targeted hacks around for things like this isn't great for maintainability. > I would welcome PMS clearly defining the scope of DESTREE and the most > logical choice of course would be src_install only where it is > currently explicitly required. Yep, as Ulrich noted (and I noted in the 2nd paragraph of my first message) PMS already defines the scope of DESTTREE to be src_install only. > If we fix java-utils-2 we should fix PMS as well. After all, > java-utils-2 is a prime suspect for the different handling of > DESTREE and for instance INSDESTREE in PMS. This asymmetry is why I > didn't touch java-utils-2 when I looked into exactly this usage of > DESTREE 2+ years ago. Just to note, I already committed the fix a few days ago after discussing it a bit on the java herd IRC channel. Really it would be great if someone was interested in reworking most of the java eclasses since they've been showing their age for a while now. Thanks, Tim pgpjO6aUuSb2m.pgp Description: PGP signature
