[gentoo-dev] [PATCH] autotools.eclass: Run eautoheader with --force

2024-09-13 Thread YiFei Zhu 
From: YiFei Zhu 

To quote Eli [1] (I can't explain it better than this):

  autotools.eclass runs autoheader without options (and in
  particular without --force). This will only remake config.h.in
  if there are actual changes to the content, which in turn means
  that it will be out of date compared to aclocal.m4 (which we very
  much expect to have changes).

  So `make` sees that the header is out of date, and runs autoheader
  yet again, this time updating the timestamp for `make` purposes.

This causes QA warning that "maintainer mode" is detected.

autoheader and autoconf added --force option at the same time [2],
so no reason only autoconf has that option in the eclass and not
autoheader.

Like, autoconf, a check on WANT_AUTOCONF != 2.1 is added because the
feature was added in autoconf 2.52.

[1] https://bugs.gentoo.org/939468#c6
[2] https://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=dbf7fc61

Closes: https://bugs.gentoo.org/939468
Closes: https://bugs.gentoo.org/939535
Signed-off-by: YiFei Zhu 
---
 eclass/autotools.eclass | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
index 0571b18ba525..641612f37193 100644
--- a/eclass/autotools.eclass
+++ b/eclass/autotools.eclass
@@ -312,7 +312,13 @@ eautoreconf() {
else
eautoconf --force
fi
-   [[ ${AT_NOEAUTOHEADER} != "yes" ]] && eautoheader
+   if [[ ${AT_NOEAUTOHEADER} != "yes" ]] ; then
+   if [[ ${WANT_AUTOCONF} == "2.1" ]] ; then
+   eautoheader
+   else
+   eautoheader --force
+   fi
+   fi
[[ ${AT_NOEAUTOMAKE} != "yes" ]] && FROM_EAUTORECONF="yes" eautomake 
${AM_OPTS}
 
if [[ ${AT_NOELIBTOOLIZE} != "yes" ]] ; then
-- 
2.46.0.662.g92d0881bb0-goog

Re: [gentoo-dev] Re: Last rites EAPI=6 packages: dev-php/*

2024-09-13 Thread Michael Orlitzky 
On 2024-09-11 17:23:16, Jaco Kroon wrote:
> 1.  Let users (myself included) just download and use that.
> 2.  We package the phar file rather than the individual deps. Yes, this 
> is cheating.  Like using embedded libs, however, I've seen and observed 
> that in some cases this makes more sense than splitting them up (eg 
> clippy and frr).
> 3.  We go about figuring everything out again and bumping all those 
> individual packages and keeping them all up to date individually.  I 
> don't think this is worth our time and effort.
> 
> I honestly think in this case 2 may well be acceptable. Otherwise 1, but 
> I think 3 is not worth the effort based on your feedback and further 
> reading from when I originally posed the question to now.

I agree that (3) is probably too much trouble. It might be worth it if
someday people want to bring back other packages that would benefit
from the deps, like PHPUnit.

I don't like (2) because there's no way for the security team to know
what's inside composer.phar, and no way for users to tell that they've
got ~15 bundled dependencies in a tool that's extremely
sensitive. So... what I've been doing is putting composer.phar in
/usr/local/bin. (I also run it as a separate user because I don't
trust the code it's downloading but that has nothing to do with
Gentoo.)

Re: [gentoo-dev] Re: Last rites EAPI=6 packages: dev-php/*

2024-09-13 Thread Jaco Kroon 

Hi,

On 2024/09/13 12:22, Michael Orlitzky wrote:


On 2024-09-11 17:23:16, Jaco Kroon wrote:

1.  Let users (myself included) just download and use that.
2.  We package the phar file rather than the individual deps. Yes, this
is cheating.  Like using embedded libs, however, I've seen and observed
that in some cases this makes more sense than splitting them up (eg
clippy and frr).
3.  We go about figuring everything out again and bumping all those
individual packages and keeping them all up to date individually.  I
don't think this is worth our time and effort.

I honestly think in this case 2 may well be acceptable. Otherwise 1, but
I think 3 is not worth the effort based on your feedback and further
reading from when I originally posed the question to now.

I agree that (3) is probably too much trouble. It might be worth it if
someday people want to bring back other packages that would benefit
from the deps, like PHPUnit.

I don't like (2) because there's no way for the security team to know
what's inside composer.phar, and no way for users to tell that they've
got ~15 bundled dependencies in a tool that's extremely
sensitive. So... what I've been doing is putting composer.phar in
/usr/local/bin. (I also run it as a separate user because I don't
trust the code it's downloading but that has nothing to do with
Gentoo.)


I think, then let's stick with that.

I'm not able to edit https://wiki.gentoo.org/wiki/Composer_packaging in 
order to make reference of this dicussion there so others looking at it 
will understand what the motivation is.  In the meantime I'm sorted at 
least.


Thanks for the constructive discussion.

Kind regards,
Jaco