Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On 19 September 2012 14:01, Matt Turner wrote:
> On Tue, Sep 18, 2012 at 9:07 PM, Ben de Groot wrote:
>> On 19 September 2012 03:18, Alec Warner wrote:
>>> On Tue, Sep 18, 2012 at 12:11 PM, Ulrich Mueller 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 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ò 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 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} !
[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} !
+# @AUTHOR:
+# Author: Michał Górny
+# Based on work of: Krzysztof Pawlik
+# @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 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 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 wrote: > On Tue, 18 Sep 2012 16:28:59 -0700 > Brian Harring 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 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 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 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 >>> 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 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 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 wrote: > On 19 September 2012 14:01, Matt Turner wrote: >> On Tue, Sep 18, 2012 at 9:07 PM, Ben de Groot wrote: >>> On 19 September 2012 03:18, Alec Warner wrote: On Tue, Sep 18, 2012 at 12:11 PM, Ulrich Mueller 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 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 ;-) -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
> 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 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 ;-) > 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 > 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 ;-) >> > > 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 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
> > 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 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 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 > 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 wrote: > On 19/09/12 03:37 PM, Ciaran McCreesh wrote: > > On Wed, 19 Sep 2012 15:26:44 -0400 Alexandre Rostovtsev > > 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 wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Wed, 19 Sep 2012 16:33:13 -0400 > Ian Stakenvicius wrote: > > On 19/09/12 03:37 PM, Ciaran McCreesh wrote: > > > On Wed, 19 Sep 2012 15:26:44 -0400 Alexandre Rostovtsev > > > 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 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 wrote: > On Wed, 19 Sep 2012 23:03:05 +0200 > Michał Górny 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 wrote: > On Wed, 19 Sep 2012 22:14:18 +0100 > Ciaran McCreesh wrote: > > On Wed, 19 Sep 2012 23:03:05 +0200 > > Michał Górny 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 wrote: > On Wed, 19 Sep 2012 23:24:29 +0200 > Michał Górny wrote: > > On Wed, 19 Sep 2012 22:14:18 +0100 > > Ciaran McCreesh wrote: > > > On Wed, 19 Sep 2012 23:03:05 +0200 > > > Michał Górny 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 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 wrote: > On Wed, 19 Sep 2012 23:39:43 +0200 > Michał Górny 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 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 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 wrote: > On Wed, 19 Sep 2012 23:18:31 +0100 > Ciaran McCreesh 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
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
Revised to use a separate variable for the name of the flag instead of
reading IUSE, as suggested by Ciaran McCreesh. As a result of this
change, vala.eclass now defaults to assuming that vala support is
optional (which is the case in an overwhelming majority of ebuilds that
would want to use this eclass).
--- a/vala.eclass
+++ b/vala.eclass
@@ -39,6 +39,19 @@
# @DESCRIPTION:
# USE dependencies that vala must be built with (e.g. vapigen).
+# @ECLASS-VARIABLE: VALA_OPTIONAL
+# @DESCRIPTION:
+# Set to "no" if vala support is not optional.
+VALA_OPTIONAL=${VALA_OPTIONAL:-yes}
+
+# @ECLASS-VARIABLE: VALA_IUSE
+# @DESCRIPTION:
+# USE flag that enables vala support in the ebuild; will be added to IUSE
unless
+# VALA_OPTIONAL is "no"; can be prefixed with '+'.
+VALA_IUSE=${VALA_IUSE:-vala}
+
+[[ ${VALA_OPTIONAL} = no ]] || IUSE=${VALA_IUSE}
+
# @FUNCTION: vala_api_versions
# @DESCRIPTION:
# Outputs a list of vala API versions from VALA_MAX_API_VERSION down to
@@ -49,17 +62,20 @@
# @FUNCTION: vala_depend
# @DESCRIPTION:
-# Outputs a ||-dependency string on vala from VALA_MAX_API_VERSION down to
-# VALA_MIN_API_VERSION
+# Outputs a ||-dependency string on vala satisfying VALA_MAX_API_VERSION,
+# VALA_MIN_API_VERSION, and VALA_USE_DEPEND. The dependency will be conditional
+# on VALA_IUSE unless vala is non-optional.
vala_depend() {
local u v versions=$(vala_api_versions)
[[ ${VALA_USE_DEPEND} ]] && u="[${VALA_USE_DEPEND}]"
+ [[ ${VALA_OPTIONAL} = no ]] || echo -n "${VALA_IUSE#[+-]}? ( "
echo -n "|| ("
for v in ${versions}; do
echo -n " dev-lang/vala:${v}${u}"
done
- echo " )"
+ echo -n " )"
+ [[ ${VALA_OPTIONAL} = no ]] || echo -n " )"
}
# @FUNCTION: vala_best_api_version
@@ -81,17 +97,24 @@
# 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 vala support is optional and disabled via USE.
+# Dies if the USE check is passed and a suitable vala version is not
+# available.
vala_src_prepare() {
local p d valafoo version
if [[ $1 = "--vala-api-version" ]]; then
version=$2
[[ ${version} ]] || die "'--vala-api-version' option requires
API version parameter."
+ fi
+
+ [[ ${VALA_OPTIONAL} = no ]] || use "${VALA_IUSE#[+-]}" || return
+
+ 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)"
+ [[ ${version} ]] || die "No installed vala in
$(VALA_OPTIONAL=no vala_depend)"
fi
export VALAC=$(type -P valac-${version})
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
El jue, 20-09-2012 a las 02:14 -0400, Alexandre Rostovtsev escribió: > Revised to use a separate variable for the name of the flag instead of > reading IUSE, as suggested by Ciaran McCreesh. As a result of this > change, vala.eclass now defaults to assuming that vala support is > optional (which is the case in an overwhelming majority of ebuilds that > would want to use this eclass). Sorry but, why even in_iuse function from eutils.eclass cannot be used? If that is really not allowed, why we have that function in eutils.eclass? There are lots of cases in eclasses relying on things like original suggested way or in_iuse from eutils.eclass and would like to clarify things before going with a more complex way than original. I already know Ciaran's opinion on this, but would like to know more opinion and, most important, is this is really allowed or not and, if not, we should try to migrate current eclasses to the "fixed" way if there is really a way providing similar function. signature.asc Description: This is a digitally signed message part
