On Tue, 1 Apr 2014 15:31:56 -0700 Tim Harder <radher...@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
signature.asc
Description: PGP signature
