Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Tue, Sep 18, 2012 at 9:07 PM, Ben de Groot yng...@gentoo.org wrote: On 19 September 2012 03:18, Alec Warner anta...@gentoo.org wrote: On Tue, Sep 18, 2012 at 12:11 PM, Ulrich Mueller u...@gentoo.org wrote: Readability is more important, and there I still don't buy the argument that the new syntax is better, and that any gain would outweigh the cost of changing. After all, the existing variables for dependency specification won't disappear, so devs would have to remember both. I agree it is a con, but is it a blocker? I mean basically any change proposed requires know the old way, and the new way..that is how changes work... Which is why changes need to have clear benefits that outweigh the costs of change. In this case the benefits are purely cosmetic, so they don't. Change for change' sake is not worth the effort. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin I'm sorry. Are you reading the same threads that I am? From the other thread (example conversion of gentoo-x86 current deps to unified dependencies): 1) This unifies the existing syntax down into a collapsed form. In doing so, there are measurable gains across the board for PM efficiency and rsync alone. 2) In unifying the syntax via reusing our /existing fucking syntax/, we formalize the adhoc common dependency assignments devs already are doing in the tree. 3) In moving to a unified syntax, it positions us to easily introduce new dependency types without introducing more redundancy. Easier to add new dep types, faster to add new dep types, more efficient in doing so in comparison to existing approaches, and done in a fashion that devs can reuse existing conditionals. 4) It is not exherbo's DEPENDENCIES. Meaning it is not label based. Meaning you do not need to knee-jerk attack it because of some notion it's ciaran based/related. I know you must have seen this (and the rest...). You've participated in that thread.
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Tue, 18 Sep 2012, Matt Turner wrote: From the other thread (example conversion of gentoo-x86 current deps to unified dependencies): [Sorry, I've missed this one in the other thread, so replying here.] 4) It is not exherbo's DEPENDENCIES. Meaning it is not label based. Meaning you do not need to knee-jerk attack it because of some notion it's ciaran based/related. What kind of reasoning is this? Does it mean that the syntax was deliberately changed to make it different from exherbo's? We should accept (or reject) things based on their technical merits, not because of ad-hominem or not invented here arguments. Ulrich
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Tue, Sep 18, 2012 at 11:36 PM, Ulrich Mueller u...@gentoo.org wrote: On Tue, 18 Sep 2012, Matt Turner wrote: From the other thread (example conversion of gentoo-x86 current deps to unified dependencies): [Sorry, I've missed this one in the other thread, so replying here.] 4) It is not exherbo's DEPENDENCIES. Meaning it is not label based. Meaning you do not need to knee-jerk attack it because of some notion it's ciaran based/related. What kind of reasoning is this? Does it mean that the syntax was deliberately changed to make it different from exherbo's? We should accept (or reject) things based on their technical merits, not because of ad-hominem or not invented here arguments. Ulrich Brian was mocking how so many people reject anything Ciaran proposes out of hand. He actually discussed the reasoning why he doesn't actually like labels in another thread.
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On 19 September 2012 14:01, Matt Turner matts...@gentoo.org wrote: On Tue, Sep 18, 2012 at 9:07 PM, Ben de Groot yng...@gentoo.org wrote: On 19 September 2012 03:18, Alec Warner anta...@gentoo.org wrote: On Tue, Sep 18, 2012 at 12:11 PM, Ulrich Mueller u...@gentoo.org wrote: Readability is more important, and there I still don't buy the argument that the new syntax is better, and that any gain would outweigh the cost of changing. After all, the existing variables for dependency specification won't disappear, so devs would have to remember both. I agree it is a con, but is it a blocker? I mean basically any change proposed requires know the old way, and the new way..that is how changes work... Which is why changes need to have clear benefits that outweigh the costs of change. In this case the benefits are purely cosmetic, so they don't. Change for change' sake is not worth the effort. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin I'm sorry. Are you reading the same threads that I am? You've seen me participating in those, so obviously: yes. From the other thread (example conversion of gentoo-x86 current deps to unified dependencies): 1) This unifies the existing syntax down into a collapsed form. In doing so, there are measurable gains across the board for PM efficiency and rsync alone. Unifying existing syntax = cosmetic If collapsing it is beneficial for PM internals, please do so internally while hiding it from ebuild devs. 2) In unifying the syntax via reusing our /existing fucking syntax/, we formalize the adhoc common dependency assignments devs already are doing in the tree. Again, cosmetic 3) In moving to a unified syntax, it positions us to easily introduce new dependency types without introducing more redundancy. Easier to add new dep types, faster to add new dep types, more efficient in doing so in comparison to existing approaches, and done in a fashion that devs can reuse existing conditionals. Again, cosmetic Note that adding new dep types only comes up very rarely. 4) It is not exherbo's DEPENDENCIES. Meaning it is not label based. Meaning you do not need to knee-jerk attack it because of some notion it's ciaran based/related. Hm, yeah, so? I know you must have seen this (and the rest...). You've participated in that thread. Indeed. So what made you wonder if I had seen that? -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] [PATCH eutils 1/2] Add dointo newinto.
On Wed, 19 Sep 2012 01:45:04 -0400 Mike Frysinger vap...@gentoo.org wrote: were you going to post an updated version for merging ? The whole idea was blocked by Diego, and was submitted for the next Council meeting. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] making USE=upnp a global flag
On Tue, 18 Sep 2012 16:55:29 -0700 Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 18/09/2012 16:50, Gilles Dartiguelongue wrote: Let me just say that as a user, concerning this technology aggregate, I really don't care, it has to just work :). Now if you gather enough momentum to split this flag and make other people on this list agree with you, I'll be just fine with it :) I'd be positive to splitting them. Especially because for instance in an office you might care about port forwarding but won't care about DLNA. Speaking of which, renaming (where applicable) upnp to dlna might be more user friendly since usually you have the feature _advertised_ as DLNA, not as UPnP! Just to make it clear: - USE=upnp for upnp-igd or nat-pmp, - USE=dlna for the video magic and so on. Do I understand correctly? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
On Sun, 9 Sep 2012 23:41:28 +0200 Michał Górny mgo...@gentoo.org wrote: Fixed to support any slot older than specified correctly. Committed. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] [PATCH 1/6] Drop pointless default S assignment.
---
gx86/eclass/python-distutils-ng.eclass | 1 -
1 file changed, 1 deletion(-)
diff --git a/gx86/eclass/python-distutils-ng.eclass
b/gx86/eclass/python-distutils-ng.eclass
index 4aecc3c..a2d5fa5 100644
--- a/gx86/eclass/python-distutils-ng.eclass
+++ b/gx86/eclass/python-distutils-ng.eclass
@@ -66,7 +66,6 @@ case ${EAPI} in
die Unsupported EAPI=${EAPI} (too old) for
python-distutils-ng.eclass ;;
4)
# EAPI=4 needed for REQUIRED_USE
- S=${S:-${WORKDIR}/${P}}
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for
python-distutils-ng.eclass ;;
--
1.7.12
[gentoo-dev] [PATCH 2/6] Move EXPORT_FUNCTIONS after the EAPI switch.
---
gx86/eclass/python-distutils-ng.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gx86/eclass/python-distutils-ng.eclass
b/gx86/eclass/python-distutils-ng.eclass
index a2d5fa5..f4c957c 100644
--- a/gx86/eclass/python-distutils-ng.eclass
+++ b/gx86/eclass/python-distutils-ng.eclass
@@ -59,8 +59,6 @@ fi
# Set to any value to disable automatic reinstallation of scripts in bin
# directories. See python-distutils-ng_src_install function.
-EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test src_install
-
case ${EAPI} in
0|1|2|3)
die Unsupported EAPI=${EAPI} (too old) for
python-distutils-ng.eclass ;;
@@ -71,6 +69,8 @@ case ${EAPI} in
die Unsupported EAPI=${EAPI} (unknown) for
python-distutils-ng.eclass ;;
esac
+EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test src_install
+
DEPEND=${DEPEND} !sys-apps/portage-2.1.10.58
# @FUNCTION: _python-distutils-ng_get_binary_for_implementation
--
1.7.12
[gentoo-dev] [PATCH 3/6] Temporarily remove PYTHON_OPTIONAL -- it is mis-designed.
Let's remove it quickly before someone starts relying on it. Hopefully,
noone outside the tree started to do that -- assumption based
on the fact that it is very unlikely for a package to want optional
distutils.
---
gx86/eclass/python-distutils-ng.eclass | 32 +++-
1 file changed, 3 insertions(+), 29 deletions(-)
diff --git a/gx86/eclass/python-distutils-ng.eclass
b/gx86/eclass/python-distutils-ng.eclass
index f4c957c..8427994 100644
--- a/gx86/eclass/python-distutils-ng.eclass
+++ b/gx86/eclass/python-distutils-ng.eclass
@@ -41,12 +41,6 @@ if [[ -z ${PYTHON_COMPAT} ]]; then
PYTHON_COMPAT+= pypy1_8 pypy1_9
fi
-# @ECLASS-VARIABLE: PYTHON_OPTIONAL
-# @DEFAULT_UNSET
-# @DESCRIPTION:
-# Set the value to yes to make the dependency on a Python interpreter
-# optional.
-
# @ECLASS-VARIABLE: PYTHON_DISABLE_COMPILATION
# @DEFAULT_UNSET
# @DESCRIPTION:
@@ -98,12 +92,7 @@ for impl in ${PYTHON_COMPAT}; do
required_use_str+= python_targets_${impl}
done
required_use_str= || ( ${required_use_str} )
-if [[ ${PYTHON_OPTIONAL} = yes ]]; then
- IUSE+= python
- REQUIRED_USE+= python? ( ${required_use_str} )
-else
- REQUIRED_USE+= ${required_use_str}
-fi
+REQUIRED_USE+= ${required_use_str}
unset required_use_str
for impl in ${PYTHON_COMPAT}; do
@@ -121,13 +110,8 @@ for impl in ${PYTHON_COMPAT}; do
esac
dep_str=python_targets_${impl}? ( ${dep_str} )
- if [[ ${PYTHON_OPTIONAL} = yes ]]; then
- RDEPEND=${RDEPEND} python? ( ${dep_str} )
- DEPEND=${DEPEND} python? ( ${dep_str} )
- else
- RDEPEND=${RDEPEND} ${dep_str}
- DEPEND=${DEPEND} ${dep_str}
- fi
+ RDEPEND=${RDEPEND} ${dep_str}
+ DEPEND=${DEPEND} ${dep_str}
unset dep_str
done
@@ -304,8 +288,6 @@ python-distutils-ng_newscript() {
# Phase function: src_prepare
python-distutils-ng_src_prepare() {
- [[ ${PYTHON_OPTIONAL} = yes ]] { use python || return; }
-
# Try to run binary for each implementation:
for impl in ${PYTHON_COMPAT}; do
use python_targets_${impl} ${PYTHON_COMPAT} || continue
@@ -336,8 +318,6 @@ python-distutils-ng_src_prepare() {
# Phase function: src_configure
python-distutils-ng_src_configure() {
- [[ ${PYTHON_OPTIONAL} = yes ]] { use python || return; }
-
if type python_configure /dev/null; then
_python-distutils-ng_run_for_each_impl python_configure
fi
@@ -345,8 +325,6 @@ python-distutils-ng_src_configure() {
# Phase function: src_compile
python-distutils-ng_src_compile() {
- [[ ${PYTHON_OPTIONAL} = yes ]] { use python || return; }
-
if type python_compile /dev/null; then
_python-distutils-ng_run_for_each_impl python_compile
else
@@ -357,8 +335,6 @@ python-distutils-ng_src_compile() {
# Phase function: src_test
python-distutils-ng_src_test() {
- [[ ${PYTHON_OPTIONAL} = yes ]] { use python || return; }
-
if type python_test /dev/null; then
_python-distutils-ng_run_for_each_impl python_test
fi
@@ -366,8 +342,6 @@ python-distutils-ng_src_test() {
# Phase function: src_install
python-distutils-ng_src_install() {
- [[ ${PYTHON_OPTIONAL} = yes ]] { use python || return; }
-
if type python_install /dev/null; then
_python-distutils-ng_run_for_each_impl python_install
else
--
1.7.12
[gentoo-dev] [PATCH 4/6] Support PYTHON_COMPAT being an array.
---
gx86/eclass/python-distutils-ng.eclass | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/gx86/eclass/python-distutils-ng.eclass
b/gx86/eclass/python-distutils-ng.eclass
index 8427994..edc38a4 100644
--- a/gx86/eclass/python-distutils-ng.eclass
+++ b/gx86/eclass/python-distutils-ng.eclass
@@ -32,6 +32,9 @@
# This variable contains a space separated list of implementations (see above)
a
# package is compatible to. It must be set before the `inherit' call. The
# default is to enable all implementations.
+#
+# PYTHON_COMPAT can be either a scalar or an array. If it's a scalar, the
eclass
+# will implicitly convert it to an array.
if [[ -z ${PYTHON_COMPAT} ]]; then
# Default: pure python, support all implementations
@@ -41,6 +44,8 @@ if [[ -z ${PYTHON_COMPAT} ]]; then
PYTHON_COMPAT+= pypy1_8 pypy1_9
fi
+PYTHON_COMPAT=( ${PYTHON_COMPAT[@]} )
+
# @ECLASS-VARIABLE: PYTHON_DISABLE_COMPILATION
# @DEFAULT_UNSET
# @DESCRIPTION:
@@ -88,14 +93,14 @@ _python-distutils-ng_get_binary_for_implementation() {
}
required_use_str=
-for impl in ${PYTHON_COMPAT}; do
+for impl in ${PYTHON_COMPAT[@]}; do
required_use_str+= python_targets_${impl}
done
required_use_str= || ( ${required_use_str} )
REQUIRED_USE+= ${required_use_str}
unset required_use_str
-for impl in ${PYTHON_COMPAT}; do
+for impl in ${PYTHON_COMPAT[@]}; do
IUSE+= python_targets_${impl}
dep_str=${impl/_/.}
case ${dep_str} in
@@ -147,8 +152,8 @@ _python-distutils-ng_run_for_impl() {
_python-distutils-ng_run_for_each_impl() {
local command=${1}
- for impl in ${PYTHON_COMPAT}; do
- use python_targets_${impl} ${PYTHON_COMPAT} || continue
+ for impl in ${PYTHON_COMPAT[@]}; do
+ use python_targets_${impl} ${PYTHON_COMPAT[@]} || continue
_python-distutils-ng_run_for_impl ${impl} ${command}
done
}
@@ -247,7 +252,7 @@ python-distutils-ng_newscript() {
local destination_directory=/usr/bin
[[ -n ${3} ]] destination_directory=${3}
- for impl in ${PYTHON_COMPAT}; do
+ for impl in ${PYTHON_COMPAT[@]}; do
use python_targets_${impl} || continue
enabled_impls=$((enabled_impls + 1))
done
@@ -274,8 +279,8 @@ python-distutils-ng_newscript() {
python-distutils-ng_rewrite_hashbang
${D}${destination_directory}/${destination_file} ${default_impl}
else
einfo Installing ${source_file} for multiple implementations
(default: ${default_impl}) in ${destination_directory}
- for impl in ${PYTHON_COMPAT}; do
- use python_targets_${impl} ${PYTHON_COMPAT} ||
continue
+ for impl in ${PYTHON_COMPAT[@]}; do
+ use python_targets_${impl} ${PYTHON_COMPAT[@]} ||
continue
newins ${source_file} ${destination_file}-${impl}
fperms 755
${destination_directory}/${destination_file}-${impl}
@@ -289,8 +294,8 @@ python-distutils-ng_newscript() {
# Phase function: src_prepare
python-distutils-ng_src_prepare() {
# Try to run binary for each implementation:
- for impl in ${PYTHON_COMPAT}; do
- use python_targets_${impl} ${PYTHON_COMPAT} || continue
+ for impl in ${PYTHON_COMPAT[@]}; do
+ use python_targets_${impl} ${PYTHON_COMPAT[@]} || continue
$(_python-distutils-ng_get_binary_for_implementation ${impl})
\
-c import sys || die
done
@@ -302,8 +307,8 @@ python-distutils-ng_src_prepare() {
fi
# Create a copy of S for each implementation:
- for impl in ${PYTHON_COMPAT}; do
- use python_targets_${impl} ${PYTHON_COMPAT} || continue
+ for impl in ${PYTHON_COMPAT[@]}; do
+ use python_targets_${impl} ${PYTHON_COMPAT[@]} || continue
einfo Creating copy for ${impl} in ${WORKDIR}/impl_${impl}
mkdir -p ${WORKDIR}/impl_${impl} || die
--
1.7.12
[gentoo-dev] [PATCH 5/6] Move PYTHON_COMPAT, IUSE and REQUIRED_USE to python-r1.
---
gx86/eclass/python-distutils-ng.eclass | 31 ++--
gx86/eclass/python-r1.eclass | 53 ++
2 files changed, 55 insertions(+), 29 deletions(-)
create mode 100644 gx86/eclass/python-r1.eclass
diff --git a/gx86/eclass/python-distutils-ng.eclass
b/gx86/eclass/python-distutils-ng.eclass
index edc38a4..5df965c 100644
--- a/gx86/eclass/python-distutils-ng.eclass
+++ b/gx86/eclass/python-distutils-ng.eclass
@@ -26,26 +26,6 @@
#each implementation and python_install_all that will be run in original
#directory (so it will not contain any implementation-specific files)
-# @ECLASS-VARIABLE: PYTHON_COMPAT
-# @DEFAULT_UNSET
-# @DESCRIPTION:
-# This variable contains a space separated list of implementations (see above)
a
-# package is compatible to. It must be set before the `inherit' call. The
-# default is to enable all implementations.
-#
-# PYTHON_COMPAT can be either a scalar or an array. If it's a scalar, the
eclass
-# will implicitly convert it to an array.
-
-if [[ -z ${PYTHON_COMPAT} ]]; then
- # Default: pure python, support all implementations
- PYTHON_COMPAT= python2_5 python2_6 python2_7
- PYTHON_COMPAT+= python3_1 python3_2
- PYTHON_COMPAT+= jython2_5
- PYTHON_COMPAT+= pypy1_8 pypy1_9
-fi
-
-PYTHON_COMPAT=( ${PYTHON_COMPAT[@]} )
-
# @ECLASS-VARIABLE: PYTHON_DISABLE_COMPILATION
# @DEFAULT_UNSET
# @DESCRIPTION:
@@ -68,6 +48,8 @@ case ${EAPI} in
die Unsupported EAPI=${EAPI} (unknown) for
python-distutils-ng.eclass ;;
esac
+inherit python-r1
+
EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test src_install
DEPEND=${DEPEND} !sys-apps/portage-2.1.10.58
@@ -92,16 +74,7 @@ _python-distutils-ng_get_binary_for_implementation() {
esac
}
-required_use_str=
-for impl in ${PYTHON_COMPAT[@]}; do
- required_use_str+= python_targets_${impl}
-done
-required_use_str= || ( ${required_use_str} )
-REQUIRED_USE+= ${required_use_str}
-unset required_use_str
-
for impl in ${PYTHON_COMPAT[@]}; do
- IUSE+= python_targets_${impl}
dep_str=${impl/_/.}
case ${dep_str} in
python?.?)
diff --git a/gx86/eclass/python-r1.eclass b/gx86/eclass/python-r1.eclass
new file mode 100644
index 000..18f9246
--- /dev/null
+++ b/gx86/eclass/python-r1.eclass
@@ -0,0 +1,53 @@
+# Copyright 1999-2012 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: $
+
+# @ECLASS: python-r1
+# @MAINTAINER:
+# Python herd pyt...@gentoo.org
+# @AUTHOR:
+# Author: Michał Górny mgo...@gentoo.org
+# Based on work of: Krzysztof Pawlik nelch...@gentoo.org
+# @BLURB: A common eclass for Python packages supporting multiple ABIs.
+# @DESCRIPTION:
+
+case ${EAPI} in
+ 0|1|2|3)
+ die Unsupported EAPI=${EAPI} (too old) for ${ECLASS}
+ ;;
+ 4)
+ # EAPI=4 needed for REQUIRED_USE
+ ;;
+ *)
+ die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
+ ;;
+esac
+
+# @ECLASS-VARIABLE: _PYTHON_ALL_IMPLS
+# @INTERNAL
+# @DESCRIPTION:
+# All supported Python implementations, most preferred first.
+_PYTHON_ALL_IMPLS=(
+ python2_7 python2_6 python2_5
+ python3_2 python3_1
+ pypy1_9 pypy1_8
+ jython2_5
+)
+
+# @ECLASS-VARIABLE: PYTHON_COMPAT
+# @DESCRIPTION:
+# This variable contains a space separated list of Pythonimplementations
+# a package supports. It must be set before the `inherit' call.
+# The default is to enable all implementations.
+#
+# PYTHON_COMPAT can be either a scalar or an array. If it's a scalar, the
eclass
+# will implicitly convert it to an array.
+: ${PYTHON_COMPAT:=${_PYTHON_ALL_IMPLS[@]}}
+
+PYTHON_COMPAT=( ${PYTHON_COMPAT[@]} )
+
+_python_set_globals() {
+ IUSE=${PYTHON_COMPAT[@]/#/python_targets_}
+ REQUIRED_USE=|| ( ${IUSE} )
+}
+_python_set_globals
--
1.7.12
[gentoo-dev] [PATCH 6/6] Generate python depstrings in python-r1.
---
gx86/eclass/python-distutils-ng.eclass | 20 ++--
gx86/eclass/python-r1.eclass | 28 ++--
2 files changed, 28 insertions(+), 20 deletions(-)
diff --git a/gx86/eclass/python-distutils-ng.eclass
b/gx86/eclass/python-distutils-ng.eclass
index 5df965c..bffe563 100644
--- a/gx86/eclass/python-distutils-ng.eclass
+++ b/gx86/eclass/python-distutils-ng.eclass
@@ -74,24 +74,8 @@ _python-distutils-ng_get_binary_for_implementation() {
esac
}
-for impl in ${PYTHON_COMPAT[@]}; do
- dep_str=${impl/_/.}
- case ${dep_str} in
- python?.?)
- dep_str=dev-lang/python:${dep_str: -3} ;;
- jython?.?)
- dep_str=dev-java/jython:${dep_str: -3} ;;
- pypy?.?)
- dep_str=dev-python/pypy:${dep_str: -3} ;;
- *)
- die Unsupported implementation: ${impl} ;;
- esac
- dep_str=python_targets_${impl}? ( ${dep_str} )
-
- RDEPEND=${RDEPEND} ${dep_str}
- DEPEND=${DEPEND} ${dep_str}
- unset dep_str
-done
+RDEPEND=${PYTHON_DEPEND}
+DEPEND=${PYTHON_DEPEND}
_PACKAGE_SPECIFIC_S=${S#${WORKDIR}/}
diff --git a/gx86/eclass/python-r1.eclass b/gx86/eclass/python-r1.eclass
index 18f9246..3017dd8 100644
--- a/gx86/eclass/python-r1.eclass
+++ b/gx86/eclass/python-r1.eclass
@@ -40,14 +40,38 @@ _PYTHON_ALL_IMPLS=(
# a package supports. It must be set before the `inherit' call.
# The default is to enable all implementations.
#
-# PYTHON_COMPAT can be either a scalar or an array. If it's a scalar, the
eclass
-# will implicitly convert it to an array.
+# PYTHON_COMPAT can be either a scalar or an array. If it's a scalar,
+# the eclass will implicitly convert it to an array.
: ${PYTHON_COMPAT:=${_PYTHON_ALL_IMPLS[@]}}
+# @ECLASS-VARIABLE: PYTHON_DEPEND
+# @DESCRIPTION:
+# This is an eclass-generated Python dependency string for all
+# implementations listed in PYTHON_COMPAT.
+
PYTHON_COMPAT=( ${PYTHON_COMPAT[@]} )
_python_set_globals() {
IUSE=${PYTHON_COMPAT[@]/#/python_targets_}
REQUIRED_USE=|| ( ${IUSE} )
+
+ PYTHON_DEPEND=
+ local i
+ for i in ${PYTHON_COMPAT[@]}; do
+ local d
+ case ${i} in
+ python*)
+ d='dev-lang/python';;
+ jython*)
+ d='dev-java/jython';;
+ pypy*)
+ d='dev-python/pypy';;
+ *)
+ die Invalid implementation: ${i}
+ esac
+
+ local v=${i##*[a-z]}
+ PYTHON_DEPEND+= python_targets_${i}? ( ${d}:${v/_/.} )
+ done
}
_python_set_globals
--
1.7.12
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Tue, 18 Sep 2012 16:28:59 -0700 Brian Harring ferri...@gmail.com wrote: pkg1 rdepends - pkg2 rdepends; this is a contained cycle, and is mergable. Do you have maybe a quick tool which could find those cycles in the tree for us? keyword there is 'usable'. Wording could be expanded, but the core notion is there- it just skips going over graph theory/resolver guts/cycles since they're not explicitly a property of dependecy types. Ah, right, I didn't notice the 'usable' in DEPEND. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: example conversion of gentoo-x86 current deps to unified dependencies
Ben de Groot posted on Wed, 19 Sep 2012 12:22:06 +0800 as excerpted: On 16 September 2012 21:15, Brian Harring ferri...@gmail.com wrote: So... basically, people are already doing this manually with their own intermediate vars. And this works fine, so it doesn't warrant a cosmetic change. @ferringb: yngwin has a point that I've not seen addressed. What /is/ wrong with the whole CDEPEND intermediate var idea? It seems to work and /I/ don't know of any problems with it (and it would appear, neither does yngwin), yet you talk about it as if there's something wrong with it. And while we're at it, do DEPEND=$RDEPEND ... style solutions have the same problems (or lack thereof)? FWIW I personally like the whole single-var idea, and CERTAINLY appreciate the various statistical cache savings, etc. If we were starting from scratch now, I'd definitely favor the single var approach. But the combined developer mental cost of having to learn the new method and then maintain a working understanding of both over some longer period is nothing to sneeze at, and I'm not entirely convinced that it's worth that cost, even assuming a doubling of the number of dependency types with a lot of commonality between them, and the added benefit a single deps var would have in that case. And the case for a single deps var isn't being helped by the implication that there's something wrong with both the intermediate var and copying var methods, without ever saying what that wrong might be, in the face of the experience of many that those existing methods just work. So if there's something wrong with them, let's get it out there where people can see it. And if there isn't, please eliminate the noise of that implication from the argument. Thanks. =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Wed, 19 Sep 2012 12:48:00 +0200 Michał Górny mgo...@gentoo.org wrote: On Tue, 18 Sep 2012 16:28:59 -0700 Brian Harring ferri...@gmail.com wrote: pkg1 rdepends - pkg2 rdepends; this is a contained cycle, and is mergable. Do you have maybe a quick tool which could find those cycles in the tree for us? I have a sneaking suspicion that any tool that could do that wouldn't be quick... Having said that, if you're after a rough idea of what we're dealing with, everything in orange deps (either directly or indirectly) upon everything else in orange: http://dev.exherbo.org/~ciaranm/resolution-fdp.png (That's a small part of Gentoo, from a while back, with X not enabled. It's far worse if X is on too.) -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc
On Wed, 19 Sep 2012 01:40:42 -0400 Mike Frysinger vap...@gentoo.org wrote: On Monday 17 September 2012 10:57:50 Alexis Ballier wrote: net-misc/wget/wget-1.14.ebuild: ~amd64-fbsd(default/bsd/fbsd/amd64/9.0) ['sys-apps/util-linux'] bumped by you, earlier, probably when you made your local change. util-_linux_ except it isn't linux specific. if you follow upstream, you'll see that people are constantly making sure that it is possible to build it on non-linux systems. well, I've never been able to build it. uuid functions are provided by either e2fsprogs-libs or the libc on freebsd. e2fsprogs-libs hasn't provided libuuid in a long time. that those are still in the tree is part laziness. relying on it to provide libuuid isn't going to work. i know, the libc ones should be used. libuuid, whereever it comes from, will always only be used during a transition period while the package is getting fixed to use the libc ones.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc
On Wed, 19 Sep 2012 01:38:51 -0400 Mike Frysinger vap...@gentoo.org wrote: On Monday 17 September 2012 08:22:50 Alexis Ballier wrote: On Sun, 16 Sep 2012 22:06:19 -0400 Mike Frysinger wrote: On Sunday 16 September 2012 11:01:00 Alexis Ballier wrote: also, you are missing some bug # for the 'broken deps' part. packages that have gained broken deps when the profile was marked 'dev', or that you committed with your profile.desc locally modified, do not count and are your fault actually... wrong. if i'm version bumping a package and i see broken amd64-fbsd deps, that is not my problem. sounds like i'll simply de-keyword it in the future and let someone else pick up the pieces. why do you want to treat amd64-fbsd different than other arches ? atm, i see amd64-fbsd as a toy arch that is impacting more negatively than it is positively. negatively ? [...] just to make the work of those that want to maintain that arch a pain ? this is why i've kept some arches which are not large in dev profiles -- so that when a new dep does come up, other devs aren't blocked. i've also communicated in the past that they should feel free to drop the keyword file a bug later so that they aren't hung up on work they're focusing on. your choice, the same choice was made for x86-fbsd; however, after years, i dont think that choice was wise and dont want to repeat the mistakes. do a repoman on the tree. there are multiple packages coming back right now with broken amd64-fbsd deps. if people do not file bugs and think it's fine to commit packages with broken deps, or silently dekeyword just because they can like you suggested in the first paragraph, this will not change anytime soon. and no thanks, i wont be doing repoman checks on the tree, i had been doing this for x86-fbsd, spending hours fixing the mess i could, and had to re-do it every couple of months because every other dev was committing packages with broken deps. except amd64-fbsd is no longer just a dev profile like x86-fbsd which means those broken deps are messing people up. people who had nothing to do with the breakage in the first place. you are missing the point here: amd64-fbsd has *never* been a dev profile. nobody should *ever* have committed something with broken deps. except because of the commit that started that thread.
Re: [gentoo-dev] [PATCH 6/6] Generate python depstrings in python-r1.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19/09/12 06:00 AM, Micha? Górny wrote:
--- gx86/eclass/python-distutils-ng.eclass | 20
++-- gx86/eclass/python-r1.eclass | 28
++-- 2 files changed, 28 insertions(+), 20
deletions(-)
diff --git a/gx86/eclass/python-distutils-ng.eclass
b/gx86/eclass/python-distutils-ng.eclass index 5df965c..bffe563
100644 --- a/gx86/eclass/python-distutils-ng.eclass +++
b/gx86/eclass/python-distutils-ng.eclass @@ -74,24 +74,8 @@
_python-distutils-ng_get_binary_for_implementation() { esac }
-for impl in ${PYTHON_COMPAT[@]}; do -dep_str=${impl/_/.} - case
${dep_str} in - python?.?) -
dep_str=dev-lang/python:${dep_str: -3} ;; - jython?.?) -
dep_str=dev-java/jython:${dep_str: -3} ;; - pypy?.?) -
dep_str=dev-python/pypy:${dep_str: -3} ;; - *) -
die
Unsupported implementation: ${impl} ;; -esac -
dep_str=python_targets_${impl}? ( ${dep_str} ) - -
RDEPEND=${RDEPEND} ${dep_str} - DEPEND=${DEPEND} ${dep_str} -
unset dep_str -done +RDEPEND=${PYTHON_DEPEND}
+DEPEND=${PYTHON_DEPEND}
_PACKAGE_SPECIFIC_S=${S#${WORKDIR}/}
diff --git a/gx86/eclass/python-r1.eclass
b/gx86/eclass/python-r1.eclass index 18f9246..3017dd8 100644 ---
a/gx86/eclass/python-r1.eclass +++ b/gx86/eclass/python-r1.eclass
@@ -40,14 +40,38 @@ _PYTHON_ALL_IMPLS=( # a package supports. It
must be set before the `inherit' call. # The default is to enable
all implementations. # -# PYTHON_COMPAT can be either a scalar or
an array. If it's a scalar, the eclass -# will implicitly convert
it to an array. +# PYTHON_COMPAT can be either a scalar or an
array. If it's a scalar, +# the eclass will implicitly convert it
to an array. : ${PYTHON_COMPAT:=${_PYTHON_ALL_IMPLS[@]}}
+# @ECLASS-VARIABLE: PYTHON_DEPEND +# @DESCRIPTION: +# This is an
eclass-generated Python dependency string for all +#
implementations listed in PYTHON_COMPAT. + PYTHON_COMPAT=(
${PYTHON_COMPAT[@]} )
_python_set_globals() { IUSE=${PYTHON_COMPAT[@]/#/python_targets_}
REQUIRED_USE=|| ( ${IUSE} ) + + PYTHON_DEPEND= +local i +
for i
in ${PYTHON_COMPAT[@]}; do + local d + case ${i} in +
python*)
+ d='dev-lang/python';; +
jython*) + d='dev-java/jython';;
+ pypy*) +
d='dev-python/pypy';; + *) +die
Invalid
implementation: ${i} + esac + +local
v=${i##*[a-z]} +
PYTHON_DEPEND+= python_targets_${i}? ( ${d}:${v/_/.} ) +done }
_python_set_globals
I think we really need to use a different variable than
PYTHON_DEPEND. There are ebuilds that inherit both python.eclass
and python-distutils-ng.eclass and so this will obviously break those
cases.. (that said, I do think that python-r1.eclass should gain
whatever bits it is missing so said inherit on python.eclass isn't
necessary, but that's beside the point)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlBZwgEACgkQ2ugaI38ACPAYCQD/UP8eEcsQygtNdNaXR6fXF1Ef
p4IYbkg/S16F372FM7MBAJkib9wdbK+3Txbvwxik5xxgtfTNmKh9iQl5DHmXRiSC
=Djl7
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: example conversion of gentoo-x86 current deps to unified dependencies
On 09/19/2012 06:59 AM, Duncan wrote: Ben de Groot posted on Wed, 19 Sep 2012 12:22:06 +0800 as excerpted: On 16 September 2012 21:15, Brian Harring ferri...@gmail.com wrote: So... basically, people are already doing this manually with their own intermediate vars. And this works fine, so it doesn't warrant a cosmetic change. @ferringb: yngwin has a point that I've not seen addressed. What /is/ wrong with the whole CDEPEND intermediate var idea? It seems to work and /I/ don't know of any problems with it (and it would appear, neither does yngwin), yet you talk about it as if there's something wrong with it. And while we're at it, do DEPEND=$RDEPEND ... style solutions have the same problems (or lack thereof)? The problem appears as we introduce more DEPEND variables (which is what prompted the proposal, IIRC). If we have ADEPEND, BDEPEND, CDEPEND, and DDEPEND, and there's only some (i.e. not total) sharing going on then the COMMON_DEPEND pattern starts to fall apart. You potentially need, AB_DEPEND AC_DEPEND AD_DEPEND BC_DEPEND BD_DEPEND CD_DEPEND ABC_DEPEND ABD_DEPEND ACD_DEPEND BCD_DEPEND ABCD_DEPEND (COMMON_DEPEND) This obviously gets worse as more DEPEND vars are introduced.
Re: [gentoo-dev] Re: example conversion of gentoo-x86 current deps to unified dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19/09/12 09:09 AM, Michael Orlitzky wrote: On 09/19/2012 06:59 AM, Duncan wrote: Ben de Groot posted on Wed, 19 Sep 2012 12:22:06 +0800 as excerpted: On 16 September 2012 21:15, Brian Harring ferri...@gmail.com wrote: So... basically, people are already doing this manually with their own intermediate vars. And this works fine, so it doesn't warrant a cosmetic change. @ferringb: yngwin has a point that I've not seen addressed. What /is/ wrong with the whole CDEPEND intermediate var idea? It seems to work and /I/ don't know of any problems with it (and it would appear, neither does yngwin), yet you talk about it as if there's something wrong with it. And while we're at it, do DEPEND=$RDEPEND ... style solutions have the same problems (or lack thereof)? The problem appears as we introduce more DEPEND variables (which is what prompted the proposal, IIRC). If we have ADEPEND, BDEPEND, CDEPEND, and DDEPEND, and there's only some (i.e. not total) sharing going on then the COMMON_DEPEND pattern starts to fall apart. You potentially need, AB_DEPEND AC_DEPEND AD_DEPEND BC_DEPEND BD_DEPEND CD_DEPEND ABC_DEPEND ABD_DEPEND ACD_DEPEND BCD_DEPEND ABCD_DEPEND (COMMON_DEPEND) This obviously gets worse as more DEPEND vars are introduced. Well not really, no -- the additional *DEPENDs that are being proposed (or at least mentioned) for new EAPI will either remove atoms from COMMON_DEPEND/DEPEND/RDEPEND or will be used so tersely that a COMMON_DEPEND or other intermediate variable won't really be necessary for them. Besides, this isn't actually a -problem- as there's nothing which really requires one to use such helpers; ebuild writers just, well, can. :) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBZxZIACgkQ2ugaI38ACPDp4wD/atjvaOsi/ntDMB1Dj7lSAVmW 45qKz6+OO+H/+6eFeVIA/Rz0s7FiG6d2frboHXpYrDBzM1FZcU85AqZti34tR8+h =E78Z -END PGP SIGNATURE-
Re: [gentoo-dev] media-video/vlc looking for a new maintainer
On 15 September 2012 04:01, Alexis Ballier aball...@gentoo.org wrote: Hi, After more than 5 years maintaining it (sh*t I'm old), I've progressively lost interest in it, to the point that I consider it is better that someone else takes care of it. So far I have dropped maintainership to the video herd but vlc usually needs more specific attention, so I fear that it may not survive long if left as such. From what I've read in various places, I'm pretty sure there are competent fellow devs interested in it, so, please step up! I will of course help the brave(s) that would take it over with what they may need to know to be at ease with the package. Alexis. Thanks for all you have done maintaining VLC all those years. It is undoubtedly one of the most popular and versatile video players out there. I really hope someone steps up to become its new dedicated maintainer. (Personally I have no interest as I use and co-maintain SMPlayer.) -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
[gentoo-dev] Inspiration
I just came across this again, and I think it could inspire us in some of our recent conversations: The Zen of Python Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! (from PEP 20: http://www.python.org/dev/peps/pep-0020/ ) So what is the Zen of Gentoo? -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Wed, 19 Sep 2012 15:12:42 +0800 Ben de Groot yng...@gentoo.org wrote: 1) This unifies the existing syntax down into a collapsed form. In doing so, there are measurable gains across the board for PM efficiency and rsync alone. Unifying existing syntax = cosmetic Not *entirely* cosmetic. If only you should have seen the scores of bug reports that got resolved by simply switching DEPEND and RDEPEND in an ebuild. Apparently a single character difference is often easy to miss, (perhaps especially in dealing with uppercase variables). It is definitely easier to spot the difference between lowercase build and run, so even a cosmetic change could be beneficial if it enhanced legibility, right? jer
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Wed, Sep 19, 2012 at 12:12 AM, Ben de Groot yng...@gentoo.org wrote: On 19 September 2012 14:01, Matt Turner matts...@gentoo.org wrote: On Tue, Sep 18, 2012 at 9:07 PM, Ben de Groot yng...@gentoo.org wrote: On 19 September 2012 03:18, Alec Warner anta...@gentoo.org wrote: On Tue, Sep 18, 2012 at 12:11 PM, Ulrich Mueller u...@gentoo.org wrote: Readability is more important, and there I still don't buy the argument that the new syntax is better, and that any gain would outweigh the cost of changing. After all, the existing variables for dependency specification won't disappear, so devs would have to remember both. I agree it is a con, but is it a blocker? I mean basically any change proposed requires know the old way, and the new way..that is how changes work... Which is why changes need to have clear benefits that outweigh the costs of change. In this case the benefits are purely cosmetic, so they don't. Change for change' sake is not worth the effort. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin I'm sorry. Are you reading the same threads that I am? You've seen me participating in those, so obviously: yes. So then you must have also read Brian's email detailing the metadata savings, and allowing the PM to parse fewer things (even with quantitative measurements!). Search your email for 'cold cache'. [snip] Looking at what you call cosmetic makes me think that you're collapsing cosmetic and a useful change down into cosmetic in order to disregard it.
Re: [gentoo-dev] [PATCH 6/6] Generate python depstrings in python-r1.
On Wed, 19 Sep 2012 09:00:49 -0400
Ian Stakenvicius a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19/09/12 06:00 AM, Micha? Górny wrote:
--- gx86/eclass/python-distutils-ng.eclass | 20
++-- gx86/eclass/python-r1.eclass | 28
++-- 2 files changed, 28 insertions(+), 20
deletions(-)
diff --git a/gx86/eclass/python-distutils-ng.eclass
b/gx86/eclass/python-distutils-ng.eclass index 5df965c..bffe563
100644 --- a/gx86/eclass/python-distutils-ng.eclass +++
b/gx86/eclass/python-distutils-ng.eclass @@ -74,24 +74,8 @@
_python-distutils-ng_get_binary_for_implementation() { esac }
-for impl in ${PYTHON_COMPAT[@]}; do - dep_str=${impl/_/.}
- case ${dep_str} in - python?.?) -
dep_str=dev-lang/python:${dep_str: -3} ;; -
jython?.?) - dep_str=dev-java/jython:${dep_str: -3} ;;
- pypy?.?) - dep_str=dev-python/pypy:${dep_str:
-3} ;; - *) -die
Unsupported implementation: ${impl} ;; - esac -
dep_str=python_targets_${impl}? ( ${dep_str} ) - -
RDEPEND=${RDEPEND} ${dep_str} - DEPEND=${DEPEND}
${dep_str} - unset dep_str -done +RDEPEND=${PYTHON_DEPEND}
+DEPEND=${PYTHON_DEPEND}
_PACKAGE_SPECIFIC_S=${S#${WORKDIR}/}
diff --git a/gx86/eclass/python-r1.eclass
b/gx86/eclass/python-r1.eclass index 18f9246..3017dd8 100644 ---
a/gx86/eclass/python-r1.eclass +++ b/gx86/eclass/python-r1.eclass
@@ -40,14 +40,38 @@ _PYTHON_ALL_IMPLS=( # a package supports. It
must be set before the `inherit' call. # The default is to enable
all implementations. # -# PYTHON_COMPAT can be either a scalar or
an array. If it's a scalar, the eclass -# will implicitly convert
it to an array. +# PYTHON_COMPAT can be either a scalar or an
array. If it's a scalar, +# the eclass will implicitly convert it
to an array. : ${PYTHON_COMPAT:=${_PYTHON_ALL_IMPLS[@]}}
+# @ECLASS-VARIABLE: PYTHON_DEPEND +# @DESCRIPTION: +# This is an
eclass-generated Python dependency string for all +#
implementations listed in PYTHON_COMPAT. + PYTHON_COMPAT=(
${PYTHON_COMPAT[@]} )
_python_set_globals() { IUSE=${PYTHON_COMPAT[@]/#/python_targets_}
REQUIRED_USE=|| ( ${IUSE} ) + + PYTHON_DEPEND= +
local i + for i in ${PYTHON_COMPAT[@]}; do +
local d + case ${i} in +
python*)
+ d='dev-lang/python';;
+ jython*) +
d='dev-java/jython';;
+ pypy*) +
d='dev-python/pypy';; + *)
+ die Invalid implementation: ${i}
+ esac + +local v=${i##*[a-z]} +
PYTHON_DEPEND+= python_targets_${i}? ( ${d}:${v/_/.} ) +
done } _python_set_globals
I think we really need to use a different variable than
PYTHON_DEPEND. There are ebuilds that inherit both python.eclass
and python-distutils-ng.eclass and so this will obviously break those
cases.. (that said, I do think that python-r1.eclass should gain
whatever bits it is missing so said inherit on python.eclass isn't
necessary, but that's beside the point)
I'm not sure if we shouldn't forbid inheriting both eclasses. That's
a bit risky, at least. And it's very likely that someone is doing
something very wrong and not noticing the failure yet.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Inspiration
On Wed, 2012-09-19 at 22:12 +0800, Ben de Groot wrote: So what is the Zen of Gentoo? How about: My set-up is better than your set-up/sarcasm ;-) -a
Re: [gentoo-dev] [PATCH 6/6] Generate python depstrings in python-r1.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19/09/12 01:37 PM, Michał Górny wrote:
On Wed, 19 Sep 2012 09:00:49 -0400 Ian Stakenvicius
a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
On 19/09/12 06:00 AM, Micha? Górny wrote:
--- gx86/eclass/python-distutils-ng.eclass | 20
++-- gx86/eclass/python-r1.eclass |
28 ++-- 2 files changed, 28
insertions(+), 20 deletions(-)
diff --git a/gx86/eclass/python-distutils-ng.eclass
b/gx86/eclass/python-distutils-ng.eclass index
5df965c..bffe563 100644 ---
a/gx86/eclass/python-distutils-ng.eclass +++
b/gx86/eclass/python-distutils-ng.eclass @@ -74,24 +74,8 @@
_python-distutils-ng_get_binary_for_implementation() { esac }
-for impl in ${PYTHON_COMPAT[@]}; do - dep_str=${impl/_/.} -
case ${dep_str} in - python?.?) -
dep_str=dev-lang/python:${dep_str: -3} ;; - jython?.?) -
dep_str=dev-java/jython:${dep_str: -3} ;; - pypy?.?) -
dep_str=dev-python/pypy:${dep_str: -3} ;; - *) -
die
Unsupported implementation: ${impl} ;; - esac -
dep_str=python_targets_${impl}? ( ${dep_str} ) - -
RDEPEND=${RDEPEND} ${dep_str} - DEPEND=${DEPEND} ${dep_str}
- unset dep_str -done +RDEPEND=${PYTHON_DEPEND}
+DEPEND=${PYTHON_DEPEND}
_PACKAGE_SPECIFIC_S=${S#${WORKDIR}/}
diff --git a/gx86/eclass/python-r1.eclass
b/gx86/eclass/python-r1.eclass index 18f9246..3017dd8 100644
--- a/gx86/eclass/python-r1.eclass +++
b/gx86/eclass/python-r1.eclass @@ -40,14 +40,38 @@
_PYTHON_ALL_IMPLS=( # a package supports. It must be set before
the `inherit' call. # The default is to enable all
implementations. # -# PYTHON_COMPAT can be either a scalar or
an array. If it's a scalar, the eclass -# will implicitly
convert it to an array. +# PYTHON_COMPAT can be either a scalar
or an array. If it's a scalar, +# the eclass will implicitly
convert it to an array. :
${PYTHON_COMPAT:=${_PYTHON_ALL_IMPLS[@]}}
+# @ECLASS-VARIABLE: PYTHON_DEPEND +# @DESCRIPTION: +# This is
an eclass-generated Python dependency string for all +#
implementations listed in PYTHON_COMPAT. + PYTHON_COMPAT=(
${PYTHON_COMPAT[@]} )
_python_set_globals() {
IUSE=${PYTHON_COMPAT[@]/#/python_targets_} REQUIRED_USE=|| (
${IUSE} ) + + PYTHON_DEPEND= + local i + for i in
${PYTHON_COMPAT[@]}; do + local d + case ${i} in + python*) +
d='dev-lang/python';; + jython*) +
d='dev-java/jython';; +
pypy*) + d='dev-python/pypy';; +*) +
die Invalid
implementation: ${i} + esac + +local
v=${i##*[a-z]} +
PYTHON_DEPEND+= python_targets_${i}? ( ${d}:${v/_/.} ) + done
} _python_set_globals
I think we really need to use a different variable than
PYTHON_DEPEND. There are ebuilds that inherit both
python.eclass and python-distutils-ng.eclass and so this will
obviously break those cases.. (that said, I do think that
python-r1.eclass should gain whatever bits it is missing so said
inherit on python.eclass isn't necessary, but that's beside the
point)
I'm not sure if we shouldn't forbid inheriting both eclasses.
That's a bit risky, at least. And it's very likely that someone is
doing something very wrong and not noticing the failure yet.
We can forbid a double-inherit, but that doesn't mean we should allow
PYTHON_DEPEND to be overloaded with two different meanings.
I would recommend instead to use 'PYTHON_DEPS'; it's different, and is
a more generic name which would seem to fit better when appended to
either/both DEPEND and RDEPEND.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlBaB74ACgkQ2ugaI38ACPD4mwD/e++PURTyeBoeFZodadFVDBYh
tBIuTaDFeuR7+PKNgPwA/1WFz8urK1ErpDLWTVsLqIUZra0L0RFG5/d+8jr3DPVQ
=bZPZ
-END PGP SIGNATURE-
Re: [gentoo-dev] Inspiration
On Wed, Sep 19, 2012 at 1:39 PM, Albert Hopkins mar...@letterboxes.org wrote: On Wed, 2012-09-19 at 22:12 +0800, Ben de Groot wrote: So what is the Zen of Gentoo? My set-up is better than your set-up/sarcasm ;-) For the 80% solution there is Ubuntu. For the 99% solution there is debian. For the other 1%, there is Gentoo. :) Rich
Re: [gentoo-dev] Inspiration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19/09/12 02:09 PM, Rich Freeman wrote: On Wed, Sep 19, 2012 at 1:39 PM, Albert Hopkins mar...@letterboxes.org wrote: On Wed, 2012-09-19 at 22:12 +0800, Ben de Groot wrote: So what is the Zen of Gentoo? My set-up is better than your set-up/sarcasm ;-) For the 80% solution there is Ubuntu. For the 99% solution there is debian. For the other 1%, there is Gentoo. :) Rich heh.. We Are The 1% .. Yeah, i see that going over REALLY well. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBaDZkACgkQ2ugaI38ACPDbXQD+NrgpiOMbDzF8g9JmAD8qOA7H F2g2w6C3GlwKp4pRcqUBAJHJVxBIUR3eu4toMkSrYKe9oT7xWFwcb5c2C8rmeMfF =7h+o -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH 6/6] Generate python depstrings in python-r1.
On Wed, 19 Sep 2012 13:58:22 -0400
Ian Stakenvicius a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19/09/12 01:37 PM, Michał Górny wrote:
On Wed, 19 Sep 2012 09:00:49 -0400 Ian Stakenvicius
a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
On 19/09/12 06:00 AM, Micha? Górny wrote:
--- gx86/eclass/python-distutils-ng.eclass | 20
++-- gx86/eclass/python-r1.eclass |
28 ++-- 2 files changed, 28
insertions(+), 20 deletions(-)
diff --git a/gx86/eclass/python-distutils-ng.eclass
b/gx86/eclass/python-distutils-ng.eclass index
5df965c..bffe563 100644 ---
a/gx86/eclass/python-distutils-ng.eclass +++
b/gx86/eclass/python-distutils-ng.eclass @@ -74,24 +74,8 @@
_python-distutils-ng_get_binary_for_implementation() { esac }
-for impl in ${PYTHON_COMPAT[@]}; do -
dep_str=${impl/_/.} - case ${dep_str} in -
python?.?) - dep_str=dev-lang/python:${dep_str: -3} ;; -
jython?.?) - dep_str=dev-java/jython:${dep_str: -3} ;;
- pypy?.?) - dep_str=dev-python/pypy:${dep_str:
-3} ;; - *) -die
Unsupported implementation: ${impl} ;; -esac -
dep_str=python_targets_${impl}? ( ${dep_str} ) - -
RDEPEND=${RDEPEND} ${dep_str} - DEPEND=${DEPEND}
${dep_str}
- unset dep_str -done +RDEPEND=${PYTHON_DEPEND}
+DEPEND=${PYTHON_DEPEND}
_PACKAGE_SPECIFIC_S=${S#${WORKDIR}/}
diff --git a/gx86/eclass/python-r1.eclass
b/gx86/eclass/python-r1.eclass index 18f9246..3017dd8 100644
--- a/gx86/eclass/python-r1.eclass +++
b/gx86/eclass/python-r1.eclass @@ -40,14 +40,38 @@
_PYTHON_ALL_IMPLS=( # a package supports. It must be set before
the `inherit' call. # The default is to enable all
implementations. # -# PYTHON_COMPAT can be either a scalar or
an array. If it's a scalar, the eclass -# will implicitly
convert it to an array. +# PYTHON_COMPAT can be either a scalar
or an array. If it's a scalar, +# the eclass will implicitly
convert it to an array. :
${PYTHON_COMPAT:=${_PYTHON_ALL_IMPLS[@]}}
+# @ECLASS-VARIABLE: PYTHON_DEPEND +# @DESCRIPTION: +# This is
an eclass-generated Python dependency string for all +#
implementations listed in PYTHON_COMPAT. + PYTHON_COMPAT=(
${PYTHON_COMPAT[@]} )
_python_set_globals() {
IUSE=${PYTHON_COMPAT[@]/#/python_targets_} REQUIRED_USE=|| (
${IUSE} ) + +PYTHON_DEPEND= + local i + for i in
${PYTHON_COMPAT[@]}; do + local d + case ${i} in +
python*) + d='dev-lang/python';; +
jython*) + d='dev-java/jython';; + pypy*) + d='dev-python/pypy';;
+ *) +die
Invalid implementation: ${i} + esac +
+ local v=${i##*[a-z]} + PYTHON_DEPEND+=
python_targets_${i}? ( ${d}:${v/_/.} ) + done }
_python_set_globals
I think we really need to use a different variable than
PYTHON_DEPEND. There are ebuilds that inherit both
python.eclass and python-distutils-ng.eclass and so this will
obviously break those cases.. (that said, I do think that
python-r1.eclass should gain whatever bits it is missing so said
inherit on python.eclass isn't necessary, but that's beside the
point)
I'm not sure if we shouldn't forbid inheriting both eclasses.
That's a bit risky, at least. And it's very likely that someone is
doing something very wrong and not noticing the failure yet.
We can forbid a double-inherit, but that doesn't mean we should allow
PYTHON_DEPEND to be overloaded with two different meanings.
I would recommend instead to use 'PYTHON_DEPS'; it's different, and is
a more generic name which would seem to fit better when appended to
either/both DEPEND and RDEPEND.
PYDEPEND :.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
[gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
Pacho Ramos has suggested making vala_src_prepare() into a no-op in the
common situation where vala is in IUSE and USE=-vala.
--- a/vala.eclass
+++ b/vala.eclass
@@ -77,20 +77,36 @@
}
# @FUNCTION: vala_src_prepare
-# @USAGE: [--vala-api-version api_version]
+# @USAGE: [--ignore-use] [--vala-api-version api_version]
# @DESCRIPTION:
# Sets up the environment variables and pkgconfig files for the
# specified API version, or, if no version is specified, for the
# highest installed vala API version satisfying
# VALA_MAX_API_VERSION, VALA_MIN_API_VERSION, and VALA_USE_DEPEND.
-# Dies if called without --vala-api-version and no suitable vala
-# version is found.
+# Is a no-op if called without --ignore-use when USE=-vala.
+# Dies if the USE check is passed (or ignored) and a suitable vala
+# version is not available.
vala_src_prepare() {
- local p d valafoo version
+ local p d valafoo version ignore_use
- if [[ $1 = --vala-api-version ]]; then
- version=$2
- [[ ${version} ]] || die '--vala-api-version' option requires
API version parameter.
+ while [[ $1 ]]; do
+ case $1 in
+ --ignore-use )
+ ignore_use=1 ;;
+ --vala-api-version )
+ shift
+ version=$1
+ [[ ${version} ]] || die '--vala-api-version'
option requires API version parameter.
+ esac
+ shift
+ done
+
+ if [[ -z ${ignore_use} ]]; then
+ has vala ${IUSE//+/} ! use vala return 0
+ fi
+
+ if [[ ${version} ]]; then
+ has_version dev-lang/vala:${version} || die No installed
vala:${version}
else
version=$(vala_best_api_version)
[[ ${version} ]] || die No installed vala in $(vala_depend)
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Wed, 19 Sep 2012 15:26:44 -0400 Alexandre Rostovtsev tetrom...@gentoo.org wrote: Pacho Ramos has suggested making vala_src_prepare() into a no-op in the common situation where vala is in IUSE and USE=-vala. There's no way to obtain the effective value of IUSE from within an ebuild or eclass. You'll need to use an independent variable to get this information. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Inspiration
On 09/19/2012 04:12 PM, Ben de Groot wrote: So what is the Zen of Gentoo? :what? ( )
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Wed, 19 Sep 2012 15:26:44 -0400
Alexandre Rostovtsev tetrom...@gentoo.org wrote:
+ if [[ -z ${ignore_use} ]]; then
+ has vala ${IUSE//+/} ! use vala return 0
+ fi
eutils.eclass: in_iuse().
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19/09/12 03:37 PM, Ciaran McCreesh wrote: On Wed, 19 Sep 2012 15:26:44 -0400 Alexandre Rostovtsev tetrom...@gentoo.org wrote: Pacho Ramos has suggested making vala_src_prepare() into a no-op in the common situation where vala is in IUSE and USE=-vala. There's no way to obtain the effective value of IUSE from within an ebuild or eclass. You'll need to use an independent variable to get this information. I don't think that the 'effective' value of IUSE matters in this particular case. This would be the 'explicit' value as is hard-coded in the ebuild that would need to be checked against, I expect? Unless eclasses and phase functions are in the habit of removing entries from IUSE, I don't see this being an issue? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBaLAkACgkQ2ugaI38ACPDeDAD9Ea1CalzAp0poqTh3mTtpwTt8 LVu5vNcZF311lIDJDE0A/jibvhrqIbB5Sw9syPvK8I0j97LGOSXPpZcfN9LYKCHF =1wDn -END PGP SIGNATURE-
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 19 Sep 2012 16:33:13 -0400 Ian Stakenvicius a...@gentoo.org wrote: On 19/09/12 03:37 PM, Ciaran McCreesh wrote: On Wed, 19 Sep 2012 15:26:44 -0400 Alexandre Rostovtsev tetrom...@gentoo.org wrote: Pacho Ramos has suggested making vala_src_prepare() into a no-op in the common situation where vala is in IUSE and USE=-vala. There's no way to obtain the effective value of IUSE from within an ebuild or eclass. You'll need to use an independent variable to get this information. I don't think that the 'effective' value of IUSE matters in this particular case. This would be the 'explicit' value as is hard-coded in the ebuild that would need to be checked against, I expect? Unless eclasses and phase functions are in the habit of removing entries from IUSE, I don't see this being an issue? No, you're not guaranteed to get the ebuild's value of IUSE, or any particular eclass's value of IUSE, or the merged value of IUSE. In particular for this case, it's possible to get false negatives. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlBaLj0ACgkQ96zL6DUtXhHGQACgtfKtKsIt1X3emCWK2qWgrFg5 y5MAn1sK5Pmf2sGFSB7j3bZJDHYr399O =ICAN -END PGP SIGNATURE-
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Wed, 19 Sep 2012 21:42:35 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 19 Sep 2012 16:33:13 -0400 Ian Stakenvicius a...@gentoo.org wrote: On 19/09/12 03:37 PM, Ciaran McCreesh wrote: On Wed, 19 Sep 2012 15:26:44 -0400 Alexandre Rostovtsev tetrom...@gentoo.org wrote: Pacho Ramos has suggested making vala_src_prepare() into a no-op in the common situation where vala is in IUSE and USE=-vala. There's no way to obtain the effective value of IUSE from within an ebuild or eclass. You'll need to use an independent variable to get this information. I don't think that the 'effective' value of IUSE matters in this particular case. This would be the 'explicit' value as is hard-coded in the ebuild that would need to be checked against, I expect? Unless eclasses and phase functions are in the habit of removing entries from IUSE, I don't see this being an issue? No, you're not guaranteed to get the ebuild's value of IUSE, or any particular eclass's value of IUSE, or the merged value of IUSE. In particular for this case, it's possible to get false negatives. Then fix the spec. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Wed, 19 Sep 2012 23:03:05 +0200 Michał Górny mgo...@gentoo.org wrote: No, you're not guaranteed to get the ebuild's value of IUSE, or any particular eclass's value of IUSE, or the merged value of IUSE. In particular for this case, it's possible to get false negatives. Then fix the spec. The spec accurately reflects the mess that is global and metadata variables. Portage has historically done all kinds of different things here (sometimes varying depending upon whether you're a binary, whether things are being loaded from VDB, whether env saving has happened previously etc), and the code is rather sensitive to apparently minor changes in bash versions. Thus we don't provide guarantees. If you want guarantees, propose something for a future EAPI. If you decide to do so, I'd be inclined to suggest proposing a function that gets the actual value of a metadata variable, rather than trying to lock down the value of globals in general. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Wed, 19 Sep 2012 22:14:18 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 19 Sep 2012 23:03:05 +0200 Michał Górny mgo...@gentoo.org wrote: No, you're not guaranteed to get the ebuild's value of IUSE, or any particular eclass's value of IUSE, or the merged value of IUSE. In particular for this case, it's possible to get false negatives. Then fix the spec. The spec accurately reflects the mess that is global and metadata variables. Portage has historically done all kinds of different things here (sometimes varying depending upon whether you're a binary, whether things are being loaded from VDB, whether env saving has happened previously etc), and the code is rather sensitive to apparently minor changes in bash versions. Thus we don't provide guarantees. The historical mess is not relevant anymore. Is there a single real case when IUSE does not contain *at least* the ebuild-set IUSE? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Wed, 19 Sep 2012 23:24:29 +0200 Michał Górny mgo...@gentoo.org wrote: On Wed, 19 Sep 2012 22:14:18 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 19 Sep 2012 23:03:05 +0200 Michał Górny mgo...@gentoo.org wrote: No, you're not guaranteed to get the ebuild's value of IUSE, or any particular eclass's value of IUSE, or the merged value of IUSE. In particular for this case, it's possible to get false negatives. Then fix the spec. The spec accurately reflects the mess that is global and metadata variables. Portage has historically done all kinds of different things here (sometimes varying depending upon whether you're a binary, whether things are being loaded from VDB, whether env saving has happened previously etc), and the code is rather sensitive to apparently minor changes in bash versions. Thus we don't provide guarantees. The historical mess is not relevant anymore. Is there a single real case when IUSE does not contain *at least* the ebuild-set IUSE? The historical mess applies to things under EAPI control. If you want stronger guarantees, you know how to propose things for a future EAPI. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Wed, 19 Sep 2012 22:31:34 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 19 Sep 2012 23:24:29 +0200 Michał Górny mgo...@gentoo.org wrote: On Wed, 19 Sep 2012 22:14:18 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 19 Sep 2012 23:03:05 +0200 Michał Górny mgo...@gentoo.org wrote: No, you're not guaranteed to get the ebuild's value of IUSE, or any particular eclass's value of IUSE, or the merged value of IUSE. In particular for this case, it's possible to get false negatives. Then fix the spec. The spec accurately reflects the mess that is global and metadata variables. Portage has historically done all kinds of different things here (sometimes varying depending upon whether you're a binary, whether things are being loaded from VDB, whether env saving has happened previously etc), and the code is rather sensitive to apparently minor changes in bash versions. Thus we don't provide guarantees. The historical mess is not relevant anymore. Is there a single real case when IUSE does not contain *at least* the ebuild-set IUSE? The historical mess applies to things under EAPI control. If you want stronger guarantees, you know how to propose things for a future EAPI. You didn't answer my question. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] [PATCH 3/3] Support specifying the USE-deps for Python impl.
As requested by hasufell.
---
gx86/eclass/python-r1.eclass | 30 ++
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/gx86/eclass/python-r1.eclass b/gx86/eclass/python-r1.eclass
index 487b5e0..9659310 100644
--- a/gx86/eclass/python-r1.eclass
+++ b/gx86/eclass/python-r1.eclass
@@ -36,14 +36,33 @@ _PYTHON_ALL_IMPLS=(
# @ECLASS-VARIABLE: PYTHON_COMPAT
# @DESCRIPTION:
-# This variable contains a space separated list of Pythonimplementations
-# a package supports. It must be set before the `inherit' call.
-# The default is to enable all implementations.
+# This variable contains a space separated list of Python
+# implementations a package supports. It must be set before
+# the `inherit' call. The default is to enable all implementations.
#
# PYTHON_COMPAT can be either a scalar or an array. If it's a scalar,
# the eclass will implicitly convert it to an array.
: ${PYTHON_COMPAT:=${_PYTHON_ALL_IMPLS[@]}}
+# @ECLASS-VARIABLE: PYTHON_COMPAT_USE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# The list of USEflags required to be enabled on the chosen Python
+# implementations, formed as a USE-dependency string. It should be valid
+# for all implementations in PYTHON_COMPAT, so it may be necessary to
+# use USE defaults.
+#
+# Example:
+# @CODE
+# PYTHON_COMPAT_USE=gdbm,ncurses(-)?
+# @CODE
+#
+# Will cause the Python dependencies to look like:
+# @CODE
+# python_targets_pythonX_Y? (
+# dev-lang/python:X_Y[gdbm,ncurses(-)?] )
+# @CODE
+
# @ECLASS-VARIABLE: PYTHON_DEPS
# @DESCRIPTION:
# This is an eclass-generated Python dependency string for all
@@ -92,7 +111,10 @@ _python_set_globals() {
esac
local v=${i##*[a-z]}
- PYTHON_DEPS+= python_targets_${i}? ( ${d}:${v/_/.} )
+ local usestr
+ [[ ${PYTHON_COMPAT_USE} ]] usestr=[${PYTHON_COMPAT_USE}]
+ PYTHON_DEPS+= python_targets_${i}? (
+ ${d}:${v/_/.}${usestr} )
done
}
_python_set_globals
--
1.7.12
[gentoo-dev] [PATCH 1/3] Generate python depstrings in python-r1 (updated).
I've renamed PYTHON_DEPEND to avoid confusion with python.eclass.
---
gx86/eclass/python-distutils-ng.eclass | 20 ++-
gx86/eclass/python-r1.eclass | 35 --
2 files changed, 35 insertions(+), 20 deletions(-)
diff --git a/gx86/eclass/python-distutils-ng.eclass
b/gx86/eclass/python-distutils-ng.eclass
index 5df965c..34717aa 100644
--- a/gx86/eclass/python-distutils-ng.eclass
+++ b/gx86/eclass/python-distutils-ng.eclass
@@ -74,24 +74,8 @@ _python-distutils-ng_get_binary_for_implementation() {
esac
}
-for impl in ${PYTHON_COMPAT[@]}; do
- dep_str=${impl/_/.}
- case ${dep_str} in
- python?.?)
- dep_str=dev-lang/python:${dep_str: -3} ;;
- jython?.?)
- dep_str=dev-java/jython:${dep_str: -3} ;;
- pypy?.?)
- dep_str=dev-python/pypy:${dep_str: -3} ;;
- *)
- die Unsupported implementation: ${impl} ;;
- esac
- dep_str=python_targets_${impl}? ( ${dep_str} )
-
- RDEPEND=${RDEPEND} ${dep_str}
- DEPEND=${DEPEND} ${dep_str}
- unset dep_str
-done
+RDEPEND=${PYTHON_DEPS}
+DEPEND=${PYTHON_DEPS}
_PACKAGE_SPECIFIC_S=${S#${WORKDIR}/}
diff --git a/gx86/eclass/python-r1.eclass b/gx86/eclass/python-r1.eclass
index 18f9246..957db68 100644
--- a/gx86/eclass/python-r1.eclass
+++ b/gx86/eclass/python-r1.eclass
@@ -40,14 +40,45 @@ _PYTHON_ALL_IMPLS=(
# a package supports. It must be set before the `inherit' call.
# The default is to enable all implementations.
#
-# PYTHON_COMPAT can be either a scalar or an array. If it's a scalar, the
eclass
-# will implicitly convert it to an array.
+# PYTHON_COMPAT can be either a scalar or an array. If it's a scalar,
+# the eclass will implicitly convert it to an array.
: ${PYTHON_COMPAT:=${_PYTHON_ALL_IMPLS[@]}}
+# @ECLASS-VARIABLE: PYTHON_DEPS
+# @DESCRIPTION:
+# This is an eclass-generated Python dependency string for all
+# implementations listed in PYTHON_COMPAT. It should be used
+# in RDEPEND and/or DEPEND like:
+#
+# @CODE
+# RDEPEND=${PYTHON_DEPS}
+# dev-foo/mydep
+# DEPEND=${RDEPEND}
+# @CODE
+
PYTHON_COMPAT=( ${PYTHON_COMPAT[@]} )
_python_set_globals() {
IUSE=${PYTHON_COMPAT[@]/#/python_targets_}
REQUIRED_USE=|| ( ${IUSE} )
+
+ PYTHON_DEPS=
+ local i
+ for i in ${PYTHON_COMPAT[@]}; do
+ local d
+ case ${i} in
+ python*)
+ d='dev-lang/python';;
+ jython*)
+ d='dev-java/jython';;
+ pypy*)
+ d='dev-python/pypy';;
+ *)
+ die Invalid implementation: ${i}
+ esac
+
+ local v=${i##*[a-z]}
+ PYTHON_DEPS+= python_targets_${i}? ( ${d}:${v/_/.} )
+ done
}
_python_set_globals
--
1.7.12
[gentoo-dev] [PATCH 2/3] Generate PYTHON_USEDEP for use in cross-package deps.
This is based on a suggestion from Ian Stakenvicius.
---
gx86/eclass/python-r1.eclass | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/gx86/eclass/python-r1.eclass b/gx86/eclass/python-r1.eclass
index 957db68..487b5e0 100644
--- a/gx86/eclass/python-r1.eclass
+++ b/gx86/eclass/python-r1.eclass
@@ -56,11 +56,25 @@ _PYTHON_ALL_IMPLS=(
# DEPEND=${RDEPEND}
# @CODE
+# @ECLASS-VARIABLE: PYTHON_USEDEP
+# @DESCRIPTION:
+# This is an eclass-generated USE-dependency string which can be used to
+# depend on another Python package being built for the same Python
+# implementations. It should be used like:
+#
+# @CODE
+# RDEPEND=dev-python/foo[${PYTHON_USEDEP}]
+# @CODE
+
PYTHON_COMPAT=( ${PYTHON_COMPAT[@]} )
_python_set_globals() {
- IUSE=${PYTHON_COMPAT[@]/#/python_targets_}
- REQUIRED_USE=|| ( ${IUSE} )
+ local flags=( ${PYTHON_COMPAT[@]/#/python_targets_} )
+ local optflags=${flags[@]/%/?}
+
+ IUSE=${flags}
+ REQUIRED_USE=|| ( ${flags} )
+ PYTHON_USEDEP=${optflags// /,}
PYTHON_DEPS=
local i
--
1.7.12
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Wed, 19 Sep 2012 23:39:43 +0200 Michał Górny mgo...@gentoo.org wrote: The historical mess is not relevant anymore. Is there a single real case when IUSE does not contain *at least* the ebuild-set IUSE? The historical mess applies to things under EAPI control. If you want stronger guarantees, you know how to propose things for a future EAPI. You didn't answer my question. Well no. The point of having a spec for all of this is that we don't have to spend a long time carefully checking things to answer this kind of question every single time a topic is discussed (and this topic has come up quite a few times). You can just look back and see the justification for the spec wording that was given. Then, if you want a change, you can get it in a future EAPI, without us having to worry about working out exactly what the impact will be. Or to put it another way, the point of having a spec is not to give you something to argue about every time it is brought up. The answer to the important question -- is this legal? -- is in the spec. The Council approved the spec. There is a process for changing the spec in a controlled manner. That's all that's relevant to this thread. If you really want to discuss archaeology, you're welcome to start another thread, and see if anyone cares to do the work to give you a detailed answer. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Wed, 19 Sep 2012 22:51:25 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 19 Sep 2012 23:39:43 +0200 Michał Górny mgo...@gentoo.org wrote: The historical mess is not relevant anymore. Is there a single real case when IUSE does not contain *at least* the ebuild-set IUSE? The historical mess applies to things under EAPI control. If you want stronger guarantees, you know how to propose things for a future EAPI. You didn't answer my question. Well no. The point of having a spec for all of this is that we don't have to spend a long time carefully checking things to answer this kind of question every single time a topic is discussed (and this topic has come up quite a few times). You can just look back and see the justification for the spec wording that was given. Then, if you want a change, you can get it in a future EAPI, without us having to worry about working out exactly what the impact will be. Yes, it did. And you are consistently wasting your and ours time complaining that we're doing illegal stuff without trying to bring even a single solution to it. Do you even care? Or are you just complaining because you don't have anything useful to do? If you care, then you should consider finding a good solution which will fix the code now, instead of saying 'it is illegal' and 'we can fix it in an awful way in next 10 years'. Or to put it another way, the point of having a spec is not to give you something to argue about every time it is brought up. You know, good specs come with a thing called 'rationale' for various points. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Thu, 20 Sep 2012 00:13:41 +0200 Michał Górny mgo...@gentoo.org wrote: Yes, it did. And you are consistently wasting your and ours time complaining that we're doing illegal stuff without trying to bring even a single solution to it. Uh, there are plenty of solutions, and they've been discussed every time this topic has come up. Do you even care? Or are you just complaining because you don't have anything useful to do? I care that people write code that actually works. If you care, then you should consider finding a good solution which will fix the code now, instead of saying 'it is illegal' and 'we can fix it in an awful way in next 10 years'. EAPI 5 doesn't appear to be 10 years off. And there are several good solutions, all of which have been discussed previously. The best is to write smaller, less convoluted eclasses that don't mix functionality and overriding default functions. Or to put it another way, the point of having a spec is not to give you something to argue about every time it is brought up. You know, good specs come with a thing called 'rationale' for various points. You're welcome to write it. You seem to have lots of free time. I'd even be happy to point you in the direction of all the previous discussions of this kind of thing, if you have difficulty finding them. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Wed, 19 Sep 2012 23:18:31 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 20 Sep 2012 00:13:41 +0200 If you care, then you should consider finding a good solution which will fix the code now, instead of saying 'it is illegal' and 'we can fix it in an awful way in next 10 years'. EAPI 5 doesn't appear to be 10 years off. And there are several good solutions, all of which have been discussed previously. The best is to write smaller, less convoluted eclasses that don't mix functionality and overriding default functions. And what can I do about it? People want it this way. Or to put it another way, the point of having a spec is not to give you something to argue about every time it is brought up. You know, good specs come with a thing called 'rationale' for various points. You're welcome to write it. You seem to have lots of free time. I'd even be happy to point you in the direction of all the previous discussions of this kind of thing, if you have difficulty finding them. Rationale should be written by the person writing the spec, don't you know? It's your words, so your rationale. Your duty. I can give my rationale for my ideas. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Thu, 20 Sep 2012 00:30:25 +0200 Michał Górny mgo...@gentoo.org wrote: On Wed, 19 Sep 2012 23:18:31 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 20 Sep 2012 00:13:41 +0200 If you care, then you should consider finding a good solution which will fix the code now, instead of saying 'it is illegal' and 'we can fix it in an awful way in next 10 years'. EAPI 5 doesn't appear to be 10 years off. And there are several good solutions, all of which have been discussed previously. The best is to write smaller, less convoluted eclasses that don't mix functionality and overriding default functions. And what can I do about it? People want it this way. You can help people write smaller, less convoluted eclasses that don't mix functionality and overriding default functions. Rationale should be written by the person writing the spec, don't you know? It's your words, so your rationale. Your duty. The general impression I get is that most people would rather we spent time on functionality and accuracy rather than history. Most people are content with the Council says so as the rationale, and are happy to restrict their queries to polite requests for historical discussion on interesting topics every now and again (and those that aren't also seem intent upon disagreeing with everything else in the spec anyway). You are of course welcome to propose to the Council that they require detailed historical background for every part of the spec, and then do your duty in writing it up if they agree. -- Ciaran McCreesh signature.asc Description: PGP signature
