php-ext-source-r2.eclass should not assume a install-headers target in php-ext-source-r2_src_install(). The offending line is this: INSTALL_ROOT="${D}" emake install-headers On php ebuilds EAPI < 4, that make use of this function, this works fine because there isn't an implicit die on emake when the install-headers target doesn't exist but on EAPI >= 4 due to the implicit die, the install fails if the package does not have an install-headers make target. I don't know how many ebuilds actually need this make install target so I propose that it stay enabled by default but there should also be a parameter for php-ext-source-r2_src_install() to disable this functionality for packages which don't have this make install target so the package can actually install and not fail due to a missing install target. Reproducible: Always
You got any package where this is a problem?
(In reply to comment #1) > You got any package where this is a problem? None in portage. I noticed this while trying to upgrade librets in bug 371707 to EAPI 4. That package doesn't have a install-headers target. So I call php-ext-source-r2_src_install under EAPI 3 and the emake fails but continues to install and function. If you flip that ebuild to EAPI 4, it will fail.
We cannot really offer explicit eclass support to packages outside of portage. It would be impossible for us to track what changes would fail and not. This particular issue is easily remedied by simply copying the src_install from the eclass into your ebuild and remove the offending line.
(In reply to comment #3) > We cannot really offer explicit eclass support to packages outside of portage. > It would be impossible for us to track what changes would fail and not. > > This particular issue is easily remedied by simply copying the src_install from > the eclass into your ebuild and remove the offending line. I understand that but the fact remains is I should not have to do that for just one line of code. I can imagine that this could be an issue for other php related ebuilds that get updated to EAPI 4.
(In reply to comment #4) > (In reply to comment #3) > > We cannot really offer explicit eclass support to packages outside of portage. > > It would be impossible for us to track what changes would fail and not. > > > > This particular issue is easily remedied by simply copying the src_install from > > the eclass into your ebuild and remove the offending line. > > I understand that but the fact remains is I should not have to do that for just > one line of code. I can imagine that this could be an issue for other php > related ebuilds that get updated to EAPI 4. I can offer a patch if you prefer.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > We cannot really offer explicit eclass support to packages outside of portage. > > > It would be impossible for us to track what changes would fail and not. > > > > > > This particular issue is easily remedied by simply copying the src_install from > > > the eclass into your ebuild and remove the offending line. > > > > I understand that but the fact remains is I should not have to do that for just > > one line of code. I can imagine that this could be an issue for other php > > related ebuilds that get updated to EAPI 4. > We are gradually moving to EAPI4 now, and so far we have not run into this issue yet. Should we see this problem with multiple ebuilds in our tree we will look into a way of fixing it within an eclass. > I can offer a patch if you prefer. Thanks, but as I said, we will not look into this unless it becomes an issue appearing more frequently.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > (In reply to comment #3) > > > > We cannot really offer explicit eclass support to packages outside of portage. > > > > It would be impossible for us to track what changes would fail and not. > > > > > > > > This particular issue is easily remedied by simply copying the src_install from > > > > the eclass into your ebuild and remove the offending line. > > > > > > I understand that but the fact remains is I should not have to do that for just > > > one line of code. I can imagine that this could be an issue for other php > > > related ebuilds that get updated to EAPI 4. > > > > We are gradually moving to EAPI4 now, and so far we have not run into this > issue yet. Should we see this problem with multiple ebuilds in our tree we will > look into a way of fixing it within an eclass. > > > I can offer a patch if you prefer. > > Thanks, but as I said, we will not look into this unless it becomes an issue > appearing more frequently. Can you offer an explanation as to what this line normally should do and why it's needed? I wonder if this is an issue specific to swig related php extensions.
(In reply to comment #1) > You got any package where this is a problem? With a quick grep through portage, looks like mapserver-6.0.1.ebuild would exhibit this problem if it was updated to EAPI 4 assuming it did not create a local function version of the eclass version in its own ebuild without that line in it.
(In reply to comment #7) > > Can you offer an explanation as to what this line normally should do and why > it's needed? I wonder if this is an issue specific to swig related php > extensions. No. It is used for when an extension want to link against another extension. E.g if you want memcache to use the igbinary serialiser. (In reply to comment #8) > (In reply to comment #1) > > You got any package where this is a problem? > > With a quick grep through portage, looks like mapserver-6.0.1.ebuild would > exhibit this problem if it was updated to EAPI 4 assuming it did not create a > local function version of the eclass version in its own ebuild without that > line in it. There is always a lot of issues with extensions that do not use php-config.
