Hi, In mandatory mod_xxx packages and EAPI=6 the depend.apache_pkg_setup is void, it does not call _init_apache2, _init_apache2_late in any path. This means that EAPI=6 is unusable. mod_nss is already affected and installed at root, I guess not tested with eapi bumped. Thanks,
*** Bug 651512 has been marked as a duplicate of this bug. ***
This is a major issue as reverse deps are getting broken when moving to eapi6 :/ I am not sure if maybe QA team would know how to fix adapt it to eapi6 Maybe define: _init_apache2_late() { APACHE_BASEDIR="/usr/$(get_libdir)/apache2" APACHE_MODULESDIR="${APACHE_BASEDIR}/modules" } in a phase instead of global scope?
I think the EAPI=6 branch for depend.apache.eclass is still buggy. In any case, we should try to move away from it: the only useful thing it does is define a few paths that ebuilds might need. It's incredibly complicated (and doesn't work!) for what it does. Instead of defining those paths as global variables (in pkg_setup or the need/want functions), we should provide functions like, apache_modules_confdir() { ... } which consumers then use when they are needed. Since nobody needs these values in pkg_setup anyway, they'll only get used in the configure, compile,install, or postinst phases. For example, the apache-module.eclass needs the module directory because it installs there: apache-module_src_install() { ... exeinto "${APACHE_MODULESDIR}" Instead, we could do something like, apache-module_src_install() { ... exeinto "$(apache_modules_dir)" which would invoke get_libdir when it's needed, and not at some probably-too-early-eapi-dependent time. If we put those functions in an -r1 of the depend.apache eclass, we could inherit it in -r0 for backwards compatibility and do e.g. APACHE_MODULESDIR="$(apache_modules_dir)" Then we could move apache-module.eclass to depend.apache.eclass-r1, fixing all of the modules at once. Afterwards, the other consumers of depend.apache.eclass could be migrated one-at-a-time.
bump. This really needs to be fixed. For example, using apache-module.eclass with EAPI 6 is not possible and installs to wrong places. For a temporary working fix, I call _init_apache2_late right from the ebuild, but that should not be the way to go.
dilfridge: I just spent some time digging into this, but I nor Lars can make sense of the changes you made to the eclass in 2016. Would you mind taking a look at this issue and see why _init_apache2_late isn't being called when you for example upgrade www-apache/mod_wsgi-4.6.5 to EAPI=6?
(In reply to Dirkjan Ochtman from comment #5) > why _init_apache2_late isn't being called when > you for example upgrade www-apache/mod_wsgi-4.6.5 to EAPI=6? apache-module.eclass inherits depend.apache.eclass which exports depend.apache_pkg_setup() which calls _init_apache2_late(). www-apache/mod_wsgi-4.6.5 has: inherit apache-module eutils python-single-r1 python-single-r1.eclass exports python-single-r1_pkg_setup(). So www-apache/mod_wsgi-4.6.5 is already broken regardless of EAPI, because it does not have: pkg_setup() { depend.apache_pkg_setup python-single-r1_pkg_setup }
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ad49fd833d609fe1a93dd7b47df70a88dddd03d4 commit ad49fd833d609fe1a93dd7b47df70a88dddd03d4 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-03-10 04:21:11 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-03-10 04:21:11 +0000 www-apache/mod_fastcgi_handler: workaround depend.apache eclass issues Bug: https://bugs.gentoo.org/616612 Closes: https://bugs.gentoo.org/653606 Signed-off-by: Sam James <sam@gentoo.org> ...handler-0.6-r1.ebuild => mod_fastcgi_handler-0.6-r2.ebuild} | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
It's not completely clear to me what was or wasn't the original issue here, but it is clear that using EAPI 6+ with depend.apache.eclass results in an installation to /. Defining the variables (for the location) in src_install then calling emake is a workaround for this.
If anyone decides to take a stab at this, I think the best way forward would be to forget about depend.apache, and just fix apache-module.eclass in a new revision. The important part of depend.apache is the variables it sets. But now that the name of "apxs" is standardized and it's installed to $PATH, you can just use e.g. APACHE_MODULESDIR=$(apxs -q libexecdir) APACHE_MODULES_CONFDIR=$(apxs -q sysconfdir)/modules.d APACHE_VHOSTS_CONFDIR=$(apxs -q sysconfdir)/vhosts.d all of which could be provided by eclass functions (in the new revision) instead of magic variables coming from depend.apache.
Created attachment 760202 [details] apache-paths.eclass
Created attachment 760204 [details] apache-module-r1.eclass Here's a band-aid for this that will allow us to get to EAPI=7 with minimum interruption. The new apache-paths eclass provides a few paths that everyone needs via function calls so it can be used in newer EAPIs. And I've made an -r1 of the apache-module eclass that uses it. To migrate an apache module ebuild, you would just switch to the new apache-module eclass, drop any function calls (like need_apache) from depend.apache, and then declare whatever additional dependencies on www-servers/apache that you need manually. The eclass declares a generic dependency on www-servers/apache only. Ideally, apache-2.eclass would also be updated to use the paths from apache-paths.eclass, so that everyone is getting the information from the same place. I've only gone to EAPI=7 because I don't feel like rewriting any more of the module eclass than I have to. As it stands, the changes are easy to audit because I've only changed a few uses of APACHE_FOO variables to apache-path-foo() function calls.
Created attachment 760205 [details] mpm_itk-2.4.7_p4-r2.ebuild I've migrated my own mpm_itk package as an example.
(In reply to Sam James from comment #8) > It's not completely clear to me what was or wasn't the original issue here, > but it is clear that using EAPI 6+ with depend.apache.eclass results in an > installation to /. > > Defining the variables (for the location) in src_install then calling emake > is a workaround for this. I use this workaround ATM: IUSE="+apache2" REQUIRED_USE="apache2" Then USE apache2 is always defined and the apache eclassel does the right thing
(In reply to Michael Orlitzky from comment #9) > If anyone decides to take a stab at this, I think the best way forward would > be to forget about depend.apache, and just fix apache-module.eclass in a new > revision. > > The important part of depend.apache is the variables it sets. But now that > the name of "apxs" is standardized and it's installed to $PATH, you can just > use e.g. > > APACHE_MODULESDIR=$(apxs -q libexecdir) > APACHE_MODULES_CONFDIR=$(apxs -q sysconfdir)/modules.d > APACHE_VHOSTS_CONFDIR=$(apxs -q sysconfdir)/vhosts.d > > all of which could be provided by eclass functions (in the new revision) > instead of magic variables coming from depend.apache. Can you send these to the ML?
(In reply to Sam James from comment #14) > > Can you send these to the ML? I've only tested the new eclasses with one package, www-apache/mpm-itk. Before proposing to merge them this really needs some love from a dedicated maintainer. (Updating the module eclass to support EAPI=8 would also be nice before ML review.)
Reassigning to apache-bugs@, because a true fix most likely requires dedicated apache maintainers to update/replace these eclasses.
