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

[Ralph Sennhauser]

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