[gentoo-dev] Re: Last rites EAPI=6 packages: dev-php/*
Hi, I missed this announcement, looking specifically for composer again. If I make the effort of bumping to newest version, is this something that would be re-added to the tree? I note there were active security vulnerabilities under very specific conditions (composer.phar is exposed via http). Or should I rather just deploy this into a local overlay? Kind regards, Jaco On 2024/06/21 19:20, Arthur Zamarin wrote: # Arthur Zamarin (2024-06-21) # Last dev-php/* EAPI=6 packages, and reverse dependencies of them. # composer has active security vulnerabilities. Others are waiting # for version bumps, and unbundling of dependencies. # Removal on 2024-07-21. Bugs #934666. dev-php/phpDocumentor dev-php/phpcov dev-php/phpdepend dev-php/phpdocumentor-reflection-common dev-php/phpdocumentor-reflection-docblock dev-php/phpdocumentor-type-resolver dev-php/stringparser_bbcode dev-php/symfony-config dev-php/symfony-console dev-php/symfony-dependency-injection dev-php/symfony-event-dispatcher dev-php/symfony-yaml dev-php/composer
[gentoo-dev] [PATCH 1/3] java-utils-2.eclass: stop mentioning java-ant-2 eclass
Signed-off-by: Volkmar W. Pogatzki
---
eclass/java-utils-2.eclass | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/eclass/java-utils-2.eclass b/eclass/java-utils-2.eclass
index 43d9b749ba3d..50e4e422db1e 100644
--- a/eclass/java-utils-2.eclass
+++ b/eclass/java-utils-2.eclass
@@ -9,13 +9,12 @@
# @SUPPORTED_EAPIS: 6 7 8
# @BLURB: Base eclass for Java packages
# @DESCRIPTION:
-# This eclass provides functionality which is used by java-pkg-2.eclass,
-# java-pkg-opt-2.eclass and java-ant-2 eclass, as well as from ebuilds.
+# This eclass provides functionality which is used by java-pkg-2.eclass and
+# java-pkg-opt-2.eclass as well as from ebuilds.
#
# This eclass should not be inherited this directly from an ebuild. Instead,
# you should inherit java-pkg-2 for Java packages or java-pkg-opt-2 for
packages
-# that have optional Java support. In addition you can inherit java-ant-2 for
-# Ant-based packages.
+# that have optional Java support.
if [[ -z ${_JAVA_UTILS_2_ECLASS} ]] ; then
_JAVA_UTILS_2_ECLASS=1
@@ -101,7 +100,7 @@ JAVA_PKG_ALLOW_VM_CHANGE=${JAVA_PKG_ALLOW_VM_CHANGE:="yes"}
# @DEFAULT_UNSET
# @DESCRIPTION:
# Specify a non-standard Java source version for compilation (via javac -source
-# parameter or Ant equivalent via build.xml rewriting done by java-ant-2
eclass).
+# parameter).
# Normally this is determined from the jdk version specified in DEPEND.
# See java-pkg_get-source function below.
#
--
2.41.0
[gentoo-dev] [PATCH 2/3] java-utils-2.eclass: remove java-pkg_check-jikes
Signed-off-by: Volkmar W. Pogatzki
---
eclass/java-utils-2.eclass | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/eclass/java-utils-2.eclass b/eclass/java-utils-2.eclass
index 50e4e422db1e..aa69cce14cae 100644
--- a/eclass/java-utils-2.eclass
+++ b/eclass/java-utils-2.eclass
@@ -203,9 +203,9 @@
JAVA_PKG_COMPILERS_CONF=${JAVA_PKG_COMPILERS_CONF:="/etc/java-config-2/build/com
#
# Useful for local testing.
#
-# Use jikes and javac, in that order
+# Use and javac, in that order
# @CODE
-# JAVA_PKG_FORCE_COMPILER="jikes javac"
+# JAVA_PKG_FORCE_COMPILER=" javac"
# @CODE
# @ECLASS_VARIABLE: JAVA_PKG_FORCE_ANT_TASKS
@@ -2306,9 +2306,6 @@ java-pkg_init() {
# TODO we will probably want to set JAVAC and JAVACFLAGS
- # Do some QA checks
- java-pkg_check-jikes
-
# Can't use unset here because Portage does not save the unset
# see https://bugs.gentoo.org/show_bug.cgi?id=189417#c11
@@ -2966,12 +2963,6 @@ java-pkg_check-versioned-jar() {
fi
}
-java-pkg_check-jikes() {
- if has jikes ${IUSE}; then
- java-pkg_announce-qa-violation "deprecated USE flag 'jikes' in
IUSE"
- fi
-}
-
java-pkg_announce-qa-violation() {
local nodie
if [[ ${1} == "--nodie" ]]; then
--
2.41.0
[gentoo-dev] [PATCH 3/3] java-pkg-2.eclass: remove unused eclass functions java-pkg-2_src_{compile,test}
The last ebuild using these functions was net-vpn/i2p-2.5.2-r1
Signed-off-by: Volkmar W. Pogatzki
---
eclass/java-pkg-2.eclass | 92 +---
1 file changed, 1 insertion(+), 91 deletions(-)
diff --git a/eclass/java-pkg-2.eclass b/eclass/java-pkg-2.eclass
index 6da4efd222c2..2b2a298cfe74 100644
--- a/eclass/java-pkg-2.eclass
+++ b/eclass/java-pkg-2.eclass
@@ -59,96 +59,6 @@ java-pkg-2_src_prepare() {
java-utils-2_src_prepare
}
-
-# @FUNCTION: java-pkg-2_src_compile
-# @DEPRECATED: none
-# @DESCRIPTION:
-# Default src_compile for java packages
-#
-# @CODE
-# Variables:
-# EANT_BUILD_XML - controls the location of the build.xml (default:
./build.xml)
-# EANT_FILTER_COMPILER - Calls java-pkg_filter-compiler with the value
-# EANT_BUILD_TARGET - the ant target/targets to execute (default: jar)
-# EANT_DOC_TARGET - the target to build extra docs under the doc use flag
-# (default: javadoc; declare empty to disable completely)
-# EANT_GENTOO_CLASSPATH - @see eant documentation in java-utils-2.eclass
-# EANT_EXTRA_ARGS - extra arguments to pass to eant
-# EANT_ANT_TASKS - modifies the ANT_TASKS variable in the eant environment
-# @CODE
-java-pkg-2_src_compile() {
- if [[ -e "${EANT_BUILD_XML:=build.xml}" ]]; then
- # auto generate classpath
- java-pkg_gen-cp EANT_GENTOO_CLASSPATH
-
- [[ "${EANT_FILTER_COMPILER}" ]] && \
- java-pkg_filter-compiler ${EANT_FILTER_COMPILER}
- local antflags="${EANT_BUILD_TARGET:=jar}"
- if has doc ${IUSE} && [[ -n "${EANT_DOC_TARGET=javadoc}" ]];
then
- antflags="${antflags} $(use_doc ${EANT_DOC_TARGET})"
- fi
- local tasks
- [[ ${EANT_ANT_TASKS} ]] && tasks="${ANT_TASKS}
${EANT_ANT_TASKS}"
- ANT_TASKS="${tasks:-${ANT_TASKS}}" \
- eant ${antflags} -f "${EANT_BUILD_XML}"
${EANT_EXTRA_ARGS} "${@}"
- else
- echo "${FUNCNAME}: ${EANT_BUILD_XML} not found so nothing to
do."
- fi
-}
-
-# @FUNCTION: java-pkg-2_src_test
-# @DEPRECATED: none
-# @DESCRIPTION:
-# src_test, not exported.
-java-pkg-2_src_test() {
- [[ -e "${EANT_BUILD_XML:=build.xml}" ]] || return
-
- if [[ ${EANT_TEST_TARGET} ]] || < "${EANT_BUILD_XML}" tr -d "\n" | grep
-Eq "]*\bname=[\"']test[\"']"; then
- local opts task_re junit_re pkg
-
- if [[ ${EANT_TEST_JUNIT_INTO} ]]; then
- java-pkg_jar-from --into "${EANT_TEST_JUNIT_INTO}" junit
- fi
-
- if [[ ${EANT_TEST_GENTOO_CLASSPATH} ]]; then
- EANT_GENTOO_CLASSPATH="${EANT_TEST_GENTOO_CLASSPATH}"
- fi
-
-
ANT_TASKS=${EANT_TEST_ANT_TASKS:-${ANT_TASKS:-${EANT_ANT_TASKS}}}
-
- task_re="\bdev-java/ant-junit(4)?(-[^:]+)?(:\S+)\b"
- junit_re="\bdev-java/junit(-[^:]+)?(:\S+)\b"
-
- if [[ ${DEPEND} =~ ${task_re} ]]; then
- pkg="ant-junit${BASH_REMATCH[1]}${BASH_REMATCH[3]}"
- pkg="${pkg%:0}"
-
- if [[ ${ANT_TASKS} && "${ANT_TASKS}" != none ]]; then
- ANT_TASKS="${ANT_TASKS} ${pkg}"
- else
- ANT_TASKS="${pkg}"
- fi
- elif [[ ${DEPEND} =~ ${junit_re} ]]; then
- pkg="junit${BASH_REMATCH[2]}"
- pkg="${pkg%:0}"
-
- opts="-Djunit.jar=\"$(java-pkg_getjar ${pkg}
junit.jar)\""
-
- if [[ ${EANT_GENTOO_CLASSPATH} ]]; then
- EANT_GENTOO_CLASSPATH+=",${pkg}"
- else
- EANT_GENTOO_CLASSPATH="${pkg}"
- fi
- fi
-
- eant ${opts} -f "${EANT_BUILD_XML}" \
- ${EANT_EXTRA_ARGS} ${EANT_TEST_EXTRA_ARGS}
${EANT_TEST_TARGET:-test}
-
- else
- echo "${FUNCNAME}: No test target in ${EANT_BUILD_XML}"
- fi
-}
-
# @FUNCTION: java-pkg-2_pkg_preinst
# @DESCRIPTION:
# wrapper for java-utils-2_pkg_preinst
@@ -158,4 +68,4 @@ java-pkg-2_pkg_preinst() {
fi
-EXPORT_FUNCTIONS pkg_setup src_prepare src_compile pkg_preinst
+EXPORT_FUNCTIONS pkg_setup src_prepare pkg_preinst
--
2.41.0
Re: [gentoo-dev] Re: Last rites EAPI=6 packages: dev-php/*
On Wed, 2024-09-11 at 09:33 +0200, Jaco Kroon wrote: > Hi, > > I missed this announcement, looking specifically for composer again. > > If I make the effort of bumping to newest version, is this something > that would be re-added to the tree? I'd re-commit if you're interested in keeping up with it. It brings a lot of dependencies with it though. It was initially added in https://github.com/gentoo/gentoo/pull/2905 (where you can see the deps) and I'll bet the list is even longer now. Updating them is more annoying than usual because they all want autoload.php files that aren't in the source tarball: https://wiki.gentoo.org/wiki/Composer_packaging IIRC the "classmap" format is particularly annoying because you have to regenerate it with every release.
Re: [gentoo-dev] Re: Last rites EAPI=6 packages: dev-php/*
Hi Michael, Looks like we keep bumping into each other ... and not only on PHP packages. n 2024/09/11 13:26, Michael Orlitzky wrote: On Wed, 2024-09-11 at 09:33 +0200, Jaco Kroon wrote: Hi, I missed this announcement, looking specifically for composer again. If I make the effort of bumping to newest version, is this something that would be re-added to the tree? I'd re-commit if you're interested in keeping up with it. It brings a lot of dependencies with it though. It was initially added in https://github.com/gentoo/gentoo/pull/2905 (where you can see the deps) and I'll bet the list is even longer now. Updating them is more annoying than usual because they all want autoload.php files that aren't in the source tarball: https://wiki.gentoo.org/wiki/Composer_packaging IIRC the "classmap" format is particularly annoying because you have to regenerate it with every release. Right. What I take away from this is that PHP trying to incorporate things that annoy me about other languages is a pain in the backside. All I really need (and I think this is in line with something you mentioned in one of our other discussions) is that PHP source files are typically no longer packaged, because everyone uses composer now to just pull in dependencies from just about anywhere, and often poorly vetted, outdated versions. What I really just need is a way to for a specific PHP deployed app be able to run composer to pull in those dependencies into a normal user account so that I can properly isolate the specific PHP app. I think it's useful to have the composer command available on Gentoo, but I do agree with the principle of letting each deployment manage it's own rather. Ie, my *opinion* is that Gentoo should package the interpreters and any pecl-* stuff which is compiled. And let the apps handle their own sources. composer I reckon is a bit of a tricky one here because it looks like it itself is a source-based thing, and pulls in a bunch of it's own deps then? Looking at what one of our clients did is they have a versioned composer.phar ... which means deps are packaged. https://getcomposer.org/download/ has these lower down, so IMHO three options here: 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. Your opinion? Kind regards, Jaco
