# ebuild /var/db/pkg/dev-php/mod_php-4.4.0-r2/mod_php-4.4.0-r2.ebuild config * Due to some previous bloopers with PHP and slotting, you may have * multiple instances of mod_php installed. Please look at the autoclean * output at the end of the emerge and unmerge all but relevant * instances. /var/db/pkg/dev-php/mod_php-4.4.0-r2/mod_php-4.4.0-r2.ebuild: line 208: //usr/sbin/apacheaddmod: No such file or directory Reproducible: Always Steps to Reproduce: 1.emerge apache (1.3.33-r12) 2.emerge mod_php 3.ebuild /var/db/pkg/dev-php/mod_php-4.4.0-r2/mod_php-4.4.0-r2.ebuild config Actual Results: /var/db/pkg/dev-php/mod_php-4.4.0-r2/mod_php-4.4.0-r2.ebuild: line 208: //usr/sbin/apacheaddmod: No such file or directory Expected Results: apache config modified to support mod_php According to http://bugs.gentoo.org/show_bug.cgi?id=85464 the apacheaddmod command is no longer part of the apache package but the provided link is not helpful. The apacheaddmod command should be either added to a package and as a dependnacy of mod_php or the ebuild needs to be modified to not need it. emerge info: # emerge info Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r1, 2.6.12-gentoo-r9 i686) ================================================================= System uname: 2.6.12-gentoo-r9 i686 AMD Athlon(tm) Processor Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5-r2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.8.1-r1, 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-mcpu=athlon-tbird -march=athlon-tbird -O2 -pipe -fomit-frame-pointer -fstack-protector -mmmx -m3dnow" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/local/clockspeed/etc /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mcpu=athlon-tbird -march=athlon-tbird -O2 -pipe -fomit-frame-pointer -fstack-protector -mmmx -m3dnow" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig notitles sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages/norad" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/FQ /usr/portage/BG" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowex acl apache1 ared aredmem berkdb bzlib cdb crypt encode fpx gd gdbm gif graphviz jbig jpeg libgd lzo lzw lzw-tiff mha mmx mng mpeg mysql mysqli nagios-dns nagios-ping nagios-s nagios-ssh ncurses nodrm nptl offensive pam perl png python readline rtc skey slang ssl tcpd tiff truetype truetype-fonts type1 type1-fonts userlocales wmf xpm zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
Re-assign back to apache; sorry for the bugspam (/me pokes CHTEKK ;p)
I guess I should post the simple workaround that I used... # cp /usr/portage/*/apache/files/apache???mod /usr/sbin/ # chmod 0700 /usr/sbin/apache???mod The files are in portage they just aren't installed by it anymore.
apache-1.3.33-r12 is also new-style, and works the same way with the eclass as apache-2.0.54-r31 does. apacheaddmod isn't supported, use the eclass. mod_php-4.4.0-r2 looks like it is for old-style apache, please use a revision that is for new-style apache.
That is easy to say however this problem happens with the latest ebuilds of mod_php and apache1. While I agree with your position that this is not a problem with apache (I never said it was) it IS a problem. This should have remained a php bug as it was originally assigned. That is where the broken ebuild file is. There is NO newer revision of mod_php that fixes this. I just tried -r3 which came out since I initially filed this report and it has the same problem. Here is the problem code from mod_php-4.4.0-r3.ebuild: pkg_config() { multiinstwarn if [ -n "${USE_APACHE2}" ]; then apache2msg else ${ROOT}/usr/sbin/apacheaddmod \ ${ROOT}/etc/apache/apache.conf \ modules/libphp4.so mod_php4.c php4_module \ before=perl define=PHP4 addconf=addon-modules/mod_php.conf :; fi }
hmmm. looking at that ebuild, you are correct. that ebuild should give nearly the same isntructions for apache-1 and apache-2. php team: your package, giving this bug to you.
(In reply to comment #3) > apache-1.3.33-r12 is also new-style, and works the same way with the eclass as > apache-2.0.54-r31 does. apacheaddmod isn't supported, use the eclass. > mod_php-4.4.0-r2 looks like it is for old-style apache, please use a revision > that is for new-style apache. Sorry, I'm really missing why removing apache functionality and causing a regression (breaking php) is a php problem. Also, I can't see any good way around it using the eclass, maybe you could be more verbose? Passing back to apache. Unless there is a really good reason to remove the above files, please revert the changes, it has caused major breakage.
Other modules broken by this: mod_layout mod_throttle mod_fastcgi mod_ldap_userdir mod_ssl mod_mp3 mod_dav mod_auth_ldap mod_contribs mod_watch mod_pcgi2 mod_auth_pgsql mod_scgi mod_gzip mod_encoding mod_bandwidth mod_chroot mod_perl Setting severity to BLOCKER, this needs urgent fix.
What's left after checking the grep results from comment #7: mod_php, mod_perl, mod_chroot (all versions need apacheaddmod) mod_contribs (p.masked, needs apacheaddmod) mod_ldap_userdir + mod_fastcgi (no version compatible w/ new layout marked stable)
*** Bug 106680 has been marked as a duplicate of this bug. ***
mod_php-4.4.0-r3, wich is the only one that has to be new-style Apache 1/2 compatible, is being fixed and should be in CVS I hope soon. Best regards, CHTEKK.
(In reply to comment #2) This work around does not work foer me. A some apache conf style files are created like apache.conf. Could somebody please post what is missing in regard to the current httpd.conf... Thanks.
The fixed mod_php-4.4.0-r3 is now in the tree. Please emerge sync again and reemerge mod_php-4.4.0-r3! Thanks a lot, and sorry for the temporary breakage. Best regards, CHTEKK.
The new ebuild does work well. The original problem with mod_php is resolved however I am going to leave this bug open just in case the other apache addons mentioned are still being worked on. If that is not the case then feel free to close it.
Do I need to open additional bugs against mod_perl and other modules broken by the changes to apache? I've been unable to get mod_perl applications, or apache to even start with mod_perl enabled. Running mod_perl-1.29. This change to apache is a big issue. Could the apache maintainers consider masking the new ebuild until the major dependent packages such as mod_perl are known to work with the changes? This was very disruptive.
php fixed, removing from CC.
(In reply to comment #14) > Could the apache maintainers consider masking the new ebuild until the major > dependent packages such as mod_perl are known to work with the changes? This was > very disruptive. This has been in ~arch since February (and p.masked before that), and all modules that depended on apache had bugs filed against them telling them to convert to the new eclass. We (the apache team) have done all we can, it is up to the specific maintainers of those other modules to fix thier modules.
*** Bug 108413 has been marked as a duplicate of this bug. ***
Please file seperate bugs for each package. None of the apache herd's packages are broken. The broken packages are maintained by other groups. apacheaddmod won't be added to new-style apache.
Why this bug was changed to WONTFIX? Looks fixed to me.
Yeah, that does look a little confusing. They will not fix the lack of apacheaddmod and apachedelmod but instead they fixed the obsolete requirement for it in mod_php (and apparently others)
