[gentoo-dev] [PATCH] fix java-utils-2 eclass to only use DESTTREE during src_install

[gentoo-dev] [PATCH] fix java-utils-2 eclass to only use DESTTREE during src_install

[Tim Harder]

[-- Attachment #1.1: Type: text/plain, Size: 1066 bytes --]

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

[-- Attachment #1.2: java-utils-2.eclass.patch --]
[-- Type: text/x-diff, Size: 699 bytes --]

--- 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}
 

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] [PATCH] fix java-utils-2 eclass to only use DESTTREE during src_install

[Ralph Sennhauser]

[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]

On Tue, 1 Apr 2014 15:31:56 -0700
Tim Harder <radhermit@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] [PATCH] fix java-utils-2 eclass to only use DESTTREE during src_install

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 455 bytes --]

>>>>> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] [PATCH] fix java-utils-2 eclass to only use DESTTREE during src_install

[Tim Harder]

[-- Attachment #1: Type: text/plain, Size: 1483 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]