[gentoo-dev] [RFC] Perspectives on improving (dis-hacking) python-single-r1
Hello,
Some aspects of the current design of python-single-r1 are gross hack.
I'd like to discuss potential alternatives to them.
Preamble
For the purpose of this mail, let's establish two terms.
'Single' will refer to packages allowing the user to select 1 out of N
supported Python implementations. This generally means programs linking
to libpython, foreign build systems and end-user apps where installing
multiple copies of the code makes no sense. Those are the packages
using python-single-r1.
'Multi' will refer to packages allowing the user to select M out of N
supported Python implementations. This generally means ebuilds for
Python packages (modules, extensions). Those are the packages using
python-r1 (usually via distutils-r1).
'Single' packages can PYTHON_USEDEP-end either on other 'single'
or on 'multi' packages. However, 'multi' packages can only
PYTHON_USEDEP-end on other 'multi' packages (because 'single' wouldn't
ever be able to satisfy >1 impl).
Current status
==
Currently, 'single' packages use two sets of USE flags: PYTHON_TARGETS
and PYTHON_SINGLE_TARGET. The latter is used to select
the implementation used, and the former is used only for technical
reasons. Selected PST is required to be also enabled in PT.
All dependencies enforce both PST and PT match. The PYTHON_USEDEP is
generally a giant hack that's meant to work both for depending
on 'single' and 'multi' packages. I'm not convinced this was the best
choice anymore.
In single-to-single deps, PYTHON_USEDEP enforces both PST and PT flags
to match. This means that if two packages have matching PST but for
some reason were built with different PT, users end up having to switch
PT and rebuild the package without any real change.
In single-to-multi deps, PYTHON_USEDEP enforces PT flags. For this
reason, we need to enforce that selected PST is always present in PT,
and users always have to put both flags in package.use.
There's also a gross hack in PYTHON_USEDEP in 'multi' packages that
means to prevent multi-to-single deps. However, the dep mismatch it
causes is not very readable.
Alternative 1: PYTHON_TARGETS only
==
The first alternative I'd like to explore is removing
PYTHON_SINGLE_TARGET flags. Why were they added in the first place?
The primary goal was to be able to set PT to 2.7+3.x without requiring
people to adjust flags for every 'single' package out there. Plus, it
turned out very convenient for Python team members who want to enable
all PT but obviously can't do the same for PST.
Originally I brought this proposal in context of automated REQUIRED_USE
conflict resolution. However, that was rejected by the Council. Still,
it may start making sense again in the near future when we start
removing py2.7 and pypy2.7 support. If we can limit PT to one
implementation, and handle the remaining packages via IUSE defaults
and package.use, this may just work.
The inconvenience to people enabling multiple PT will remain though.
Alternative 2: new dependency API
=
If PST is going to stay, we may look into removing PT from 'single'
packages instead. The idea is to provide new method of generating
cross-package deps that doesn't require fake flags.
PYTHON_USEDEP would continue working through a transitional period.
When it's entirely gone, we can remove PYTHON_TARGETS from 'single'
packages.
Single-to-single deps would switch to PYTHON_SINGLE_USEDEP, that only
enforces PST and disregards PT entirely.
Single-to-multi deps would have to use a new generator function,
$(python_gen_multi_dep ...) that would create appropriate USE-mapping
from PST to PT.
Example ebuild would have:
RDEPEND="app-foo/singlepkg[${PYTHON_SINGLE_USEDEP}]
$(python_gen_multi_dep '
dev-python/foo[${PYTHON_USEDEP}]
dev-python/bar[${PYTHON_USEDEP}]
')"
This will generate something like:
pst_python2_7? (
dev-python/foo[pt_python2_7(-)]
dev-python/bar[pt_python2_7(-)]
)
pst_python3_7? (
dev-python/foo[pt_python3_7(-)]
dev-python/bar[pt_python3_7(-)]
)
Your opinions
=
So, WDYT? Do you think this approach is worthwhile? Do you see other
options?
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH] eutils.eclass: Drop epause() and ebeep().
No ebuilds calling these functions in EAPIs 0 to 2 are left in the tree.
Signed-off-by: Ulrich Müller
---
eclass/eutils.eclass | 49 +---
1 file changed, 1 insertion(+), 48 deletions(-)
diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index 7b6336e2aee1..20dec774f2f5 100644
--- a/eclass/eutils.eclass
+++ b/eclass/eutils.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2018 Gentoo Foundation
+# Copyright 1999-2019 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: eutils.eclass
@@ -231,53 +231,6 @@ optfeature() {
fi
}
-case ${EAPI:-0} in
-0|1|2)
-
-# @FUNCTION: epause
-# @USAGE: [seconds]
-# @DESCRIPTION:
-# Sleep for the specified number of seconds (default of 5 seconds). Useful
when
-# printing a message the user should probably be reading and often used in
-# conjunction with the ebeep function. If the EPAUSE_IGNORE env var is set,
-# don't wait at all. Defined in EAPIs 0 1 and 2.
-epause() {
- [[ -z ${EPAUSE_IGNORE} ]] && sleep ${1:-5}
-}
-
-# @FUNCTION: ebeep
-# @USAGE: [number of beeps]
-# @DESCRIPTION:
-# Issue the specified number of beeps (default of 5 beeps). Useful when
-# printing a message the user should probably be reading and often used in
-# conjunction with the epause function. If the EBEEP_IGNORE env var is set,
-# don't beep at all. Defined in EAPIs 0 1 and 2.
-ebeep() {
- local n
- if [[ -z ${EBEEP_IGNORE} ]] ; then
- for ((n=1 ; n <= ${1:-5} ; n++)) ; do
- echo -ne "\a"
- sleep 0.1 &>/dev/null ; sleep 0,1 &>/dev/null
- echo -ne "\a"
- sleep 1
- done
- fi
-}
-
-;;
-*)
-
-ebeep() {
- ewarn "QA Notice: ebeep is not defined in EAPI=${EAPI}, please file a
bug at https://bugs.gentoo.org;
-}
-
-epause() {
- ewarn "QA Notice: epause is not defined in EAPI=${EAPI}, please file a
bug at https://bugs.gentoo.org;
-}
-
-;;
-esac
-
case ${EAPI:-0} in
0|1|2|3|4)
--
2.24.0
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH] estack.eclass: Drop isdigit function.
It isn't (and never was) used by anything else in the tree. Inline its
only usage in evar_pop() and drop the function.
---
eclass/estack.eclass | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/eclass/estack.eclass b/eclass/estack.eclass
index b0177bdb358e..2aa6f366dc12 100644
--- a/eclass/estack.eclass
+++ b/eclass/estack.eclass
@@ -115,7 +115,8 @@ evar_pop() {
local cnt=${1:-bad}
case $# in
0) cnt=1 ;;
- 1) isdigit "${cnt}" || die "${FUNCNAME}: first arg must be a number:
$*" ;;
+ 1) [[ -z ${cnt//[0-9]} ]] \
+ || die "${FUNCNAME}: first arg must be a number: $*" ;;
*) die "${FUNCNAME}: only accepts one arg: $*" ;;
esac
@@ -197,17 +198,5 @@ eumask_pop() {
umask ${s} || die "${FUNCNAME}: sanity: could not restore umask: ${s}"
}
-# @FUNCTION: isdigit
-# @USAGE: [more numbers]
-# @DESCRIPTION:
-# Return true if all arguments are numbers.
-isdigit() {
- local d
- for d ; do
- [[ ${d:-bad} == *[!0-9]* ]] && return 1
- done
- return 0
-}
-
_ESTACK_ECLASS=1
fi #_ESTACK_ECLASS
--
2.24.0
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH] estack.eclass: Properly restore shopt options.
Calling "eshopts_push; eshopts_pop" makes Portage report a QA issue:
* QA Notice: Global shell options changed and were not restored while calling
'src_prepare'
This is caused by some side effect, by which restoring the noglob
option disables the expand_aliases option. Work around the problem
by always saving and restoring both "set -o" and "shopt" option sets.
Also fix "estack_push -s" which should not execute shopt when called
without further parameters.
Closes: https://bugs.gentoo.org/662586
Signed-off-by: Ulrich Müller
---
eclass/estack.eclass | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/eclass/estack.eclass b/eclass/estack.eclass
index f548abf8c283..b0177bdb358e 100644
--- a/eclass/estack.eclass
+++ b/eclass/estack.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2017 Gentoo Foundation
+# Copyright 1999-2019 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: estack.eclass
@@ -153,12 +153,13 @@ evar_pop() {
# eshopts_pop
# @CODE
eshopts_push() {
+ # Save both "shopt" and "set -o" option sets, because otherwise
+ # restoring noglob would disable expand_aliases by side effect. #662586
+ estack_push eshopts "$(shopt -p -o) $(shopt -p)"
if [[ $1 == -[su] ]] ; then
- estack_push eshopts "$(shopt -p)"
- [[ $# -eq 0 ]] && return 0
+ [[ $# -le 1 ]] && return 0
shopt "$@" || die "${FUNCNAME}: bad options to shopt: $*"
else
- estack_push eshopts "$(shopt -p -o)"
[[ $# -eq 0 ]] && return 0
set "$@" || die "${FUNCNAME}: bad options to set: $*"
fi
--
2.24.0
signature.asc
Description: PGP signature
Re: [gentoo-dev] toolchain.eclass more friendly about ada/gnat
On Sat, 23 Nov 2019 09:16:42 +0100
Alfredo Tupone wrote:
> I would like to have comments about the followinf changes.
> I "fear" the shopts nullglob a little
>
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index a3081c38bac1..aca10b4f37ed 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -1817,33 +1817,37 @@ toolchain_src_install() {
> fi
>
> dodir /etc/env.d/gcc
> create_gcc_env_entry
> create_revdep_rebuild_entry
>
> # Setup the gcc_env_entry for hardened gcc 4 with minispecs
> want_minispecs && copy_minispecs_gcc_specs
>
> # Make sure we dont have stuff lying around that
> # can nuke multiple versions of gcc
> gcc_slot_java
>
> dodir /usr/bin
> cd "${D}"${BINPATH}
> +
> + shopt nullglob
> + local gnat_extra_bins="gnat*"
> +
> # Ugh: we really need to auto-detect this list.
> # It's constantly out of date.
> - for x in cpp gcc g++ c++ gcov g77 gcj gcjh gfortran gccgo ; do
> + for x in cpp gcc g++ c++ gcov g77 gcj gcjh gfortran gccgo
> ${gnat_extra_bins} ; do
You can also drop 'shopt nullglob'/'local gnat_extra_bins="gnat*"' and use
'gnat*' directly:
for x in ... gnat* ; do
All the code below if guarded by [[ -f ${x} ]] anyway.
> # For some reason, g77 gets made instead of ${CTARGET}-g77...
> # this should take care of that
> if [[ -f ${x} ]] ; then
> # In case they're hardlinks, clear out the target first
> # otherwise the mv below will complain.
> rm -f ${CTARGET}-${x}
> mv ${x} ${CTARGET}-${x}
> fi
>
> if [[ -f ${CTARGET}-${x} ]] ; then
> if ! is_crosscompile ; then
> ln -sf ${CTARGET}-${x} ${x}
> dosym ${BINPATH#${EPREFIX}}/${CTARGET}-${x} \
> /usr/bin/${x}-${GCC_CONFIG_VER}
> fi
>
--
Sergei
[gentoo-dev] toolchain.eclass more friendly about ada/gnat
I would like to have comments about the followinf changes.
I "fear" the shopts nullglob a little
diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index a3081c38bac1..aca10b4f37ed 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -1817,33 +1817,37 @@ toolchain_src_install() {
fi
dodir /etc/env.d/gcc
create_gcc_env_entry
create_revdep_rebuild_entry
# Setup the gcc_env_entry for hardened gcc 4 with minispecs
want_minispecs && copy_minispecs_gcc_specs
# Make sure we dont have stuff lying around that
# can nuke multiple versions of gcc
gcc_slot_java
dodir /usr/bin
cd "${D}"${BINPATH}
+
+ shopt nullglob
+ local gnat_extra_bins="gnat*"
+
# Ugh: we really need to auto-detect this list.
# It's constantly out of date.
- for x in cpp gcc g++ c++ gcov g77 gcj gcjh gfortran gccgo ; do
+ for x in cpp gcc g++ c++ gcov g77 gcj gcjh gfortran gccgo
${gnat_extra_bins} ; do
# For some reason, g77 gets made instead of ${CTARGET}-g77...
# this should take care of that
if [[ -f ${x} ]] ; then
# In case they're hardlinks, clear out the target first
# otherwise the mv below will complain.
rm -f ${CTARGET}-${x}
mv ${x} ${CTARGET}-${x}
fi
if [[ -f ${CTARGET}-${x} ]] ; then
if ! is_crosscompile ; then
ln -sf ${CTARGET}-${x} ${x}
dosym ${BINPATH#${EPREFIX}}/${CTARGET}-${x} \
/usr/bin/${x}-${GCC_CONFIG_VER}
fi
