[gentoo-dev] Re: python-distutils-ng.eclass: allow useflag dependencies for python
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 09/06/2012 05:27 PM, Brian Harring wrote:
> On Thu, Sep 06, 2012 at 10:44:34PM +0200, hasufell wrote:
>> -dep_str="dev-lang/python:${dep_str: -3}" ;; +
>> dep_str="dev-lang/python:${dep_str: -3}${_PYTHON_USE}" ;;
> should I ask wth the space is for?
>
Without the space, ${dep_str:-3} means "${dep_str} unless empty or
unset, otherwise 3"; with the space, ${dep_str: -3} (can also be
written ${dep_str:(-3)}) means "the last 3 characters of ${dep_str}".
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCgAGBQJQSSzXAAoJELHSF2kinlg4UMUP/1xlAEhmy9JfDp//IPssBZ6g
SsO1eNbPjFtU8bFAWDAcbCMQ4c4bYB7xeAYCwn90qccpYiyOqftWCRiF5CPdou0T
ntUp2dpPkps1NkuuxSEwfk2jr91s38ri8GA3WOlT4AjADhjjjpIQjn7ib9SVYKVj
ZywHrwxjpHlkR7SaALAriwg6hkkrdtNKVtqnWyGKfx570e0rGJk+EK5SbnwtzHaD
ttmKkSFcHrkyPamTrmLa2udjqnnVMi0wuRi8IC5NP5AgF3osj91fqq1waBpViXxL
UVB397OpsHwXxP5uAWJ6O8eFPviCq8HcstRCg+XXnBIdyQYQcVB80aA+r+kfqfjI
d2WGBS5wNwYILGW1L5S5z5tcGibJKkraCvwI2vhNYItzL43X2oBuuiwVKo7u0cd2
P04g3vwBAfcMvGKo/GFWyUGvsLrdl9Fcnmiyv86XvJSo8guhx0NO628x/4uFY+uU
/IsbgXcWCC48HLmLqypE+kBVofkR7nWGNecEvHlgTe/4oLzpyJzOj/5bgTUbioW+
w9Rj/0S3K/GOYYfbBjvsQKH3vSuYqPP2/6KuG5N/r98lCtkaRujfxj7t7NlSqRT0
1XGr9Y+YZlE6YBQ/JjrfsOH9uotohvutY2aIxUlfe1MFjbixI3Q7p/9EWaZ89Cwq
8saYFqjaWfe9lHmwxxbJ
=x+TM
-END PGP SIGNATURE-
Re: [gentoo-dev] python-distutils-ng.eclass: allow useflag dependencies for python
On Thu, Sep 06, 2012 at 10:44:34PM +0200, hasufell wrote:
> I am missing a replacement for PYTHON_USE_WITH.
>
> Would the attached patch help in any way? Review? Other ideas?
> --- python-distutils-ng.eclass
> +++ python-distutils-ng.eclass
> @@ -59,6 +59,25 @@
> # Set to any value to disable automatic reinstallation of scripts in bin
> # directories. See python-distutils-ng_src_install function.
>
> +# @ECLASS-VARIABLE: PYTHON_USE
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# comma seperated list of useflags needed for python
> +# this is directly substituted into dev-lang/python[${PYTHON_USE}] thus
> allowing
> +# all valid useflag dependencies
> +# example 1: PYTHON_USE="xml,sqlite"
> +# example 2: PYTHON_USE="xml?,threads?,-foo"
> +
> +# @ECLASS-VARIABLE: JYTHON_USE
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# same as PYTHON_USE just for JYTHON
> +
> +# @ECLASS-VARIABLE: PYPY_USE
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# same as PYTHON_USE just for PYPY
> +
> EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test src_install
>
> case "${EAPI}" in
> @@ -107,16 +126,22 @@
> fi
> unset required_use_str
>
> +# avoid empty use deps
> +[[ -n ${PYTHON_USE} ]] && _PYTHON_USE="[${PYTHON_USE}]" || _PYTHON_USE=""
> +[[ -n ${JYTHON_USE} ]] && _JYTHON_USE="[${JYTHON_USE}]" || _JYTHON_USE=""
> +[[ -n ${PYPY_USE} ]] && _PYPY_USE="[${PYPY_USE}]" || _PYPY_USE=""
Ick.
_PYTHON_USE="${PYTHON_USE:+[${PYTHON_USE}]}"
_JYTHON_USE="${JYTHON_USE:+[${JYTHON_USE}]}"
_PYPY_USE="${PYPY_USE:+[${PYPY_USE}]}"
> +
> +# set python DEPEND and RDEPEND
> for impl in ${PYTHON_COMPAT}; do
> IUSE+=" python_targets_${impl}"
> dep_str="${impl/_/.}"
> case "${dep_str}" in
> python?.?)
> - dep_str="dev-lang/python:${dep_str: -3}" ;;
> + dep_str="dev-lang/python:${dep_str: -3}${_PYTHON_USE}"
> ;;
should I ask wth the space is for?
> jython?.?)
> - dep_str="dev-java/jython:${dep_str: -3}" ;;
> + dep_str="dev-java/jython:${dep_str: -3}${_JYTHON_USE}"
> ;;
> pypy?.?)
> - dep_str="dev-python/pypy:${dep_str: -3}" ;;
> + dep_str="dev-python/pypy:${dep_str: -3}${_PYPY_USE}" ;;
> *)
> die "Unsupported implementation: ${impl}" ;;
> esac
Re: [gentoo-dev] EAPI usage
On Sep 6, 2012 10:18 AM, "Michael Orlitzky" wrote: > > On 09/05/2012 05:29 PM, Brian Harring wrote: > > > > Yes, I stated it because I view it as useful/sane. > > > >> and isn't a compromise at all. > > > > I think you're mistaken in assuming a compromise is the required > > outcome of this. Given the choice between something productive, and > > something not productive, you don't choose the quasi-productive > > solution. > > From a developer's perspective, it's obviously better to be able to do > whatever you want. But for users it'd be nice to be able to request a > bump to EAPI5 and not get told to buzz off. > > Some people are unhappy with the current situation or this thread > wouldn't exist. A good compromise should make everyone just a little bit > unhappy =) Open source is built on scratching your own itch. As I said, you want eapi5 for user patching, either you're on the devs prioritization, or you do it yourself. You may not like that fact, but that *is* reality- filing nagging tickets isn't really going to help (more likely to piss people off in the same way zero-day tickets do). Suggest you put effort towards eapi5 rather than this thread; the thread isn't productive any longer (arguing the point when people have said no in full force is pointless). ~harring >
Re: [gentoo-dev] python-distutils-ng.eclass: allow useflag dependencies for python
On Thu, 06 Sep 2012 22:44:34 +0200
hasufell wrote:
> --- python-distutils-ng.eclass
> +++ python-distutils-ng.eclass
> @@ -59,6 +59,25 @@
> # Set to any value to disable automatic reinstallation of scripts in
> bin # directories. See python-distutils-ng_src_install function.
>
> +# @ECLASS-VARIABLE: PYTHON_USE
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# comma seperated list of useflags needed for python
> +# this is directly substituted into dev-lang/python[${PYTHON_USE}]
> thus allowing +# all valid useflag dependencies
> +# example 1: PYTHON_USE="xml,sqlite"
> +# example 2: PYTHON_USE="xml?,threads?,-foo"
> +
> +# @ECLASS-VARIABLE: JYTHON_USE
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# same as PYTHON_USE just for JYTHON
> +
> +# @ECLASS-VARIABLE: PYPY_USE
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# same as PYTHON_USE just for PYPY
> +
Why I feel like we're close to PYTHON2_USE, PYTHON3_USE,
PYTHON3NG_USE...
> EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test
> src_install
> case "${EAPI}" in
> @@ -107,16 +126,22 @@
> fi
> unset required_use_str
>
> +# avoid empty use deps
> +[[ -n ${PYTHON_USE} ]] && _PYTHON_USE="[${PYTHON_USE}]" ||
> _PYTHON_USE="" +[[ -n ${JYTHON_USE} ]] &&
> _JYTHON_USE="[${JYTHON_USE}]" || _JYTHON_USE="" +[[ -n ${PYPY_USE} ]]
> && _PYPY_USE="[${PYPY_USE}]" || _PYPY_USE="" +
> +# set python DEPEND and RDEPEND
> for impl in ${PYTHON_COMPAT}; do
> IUSE+=" python_targets_${impl}"
> dep_str="${impl/_/.}"
> case "${dep_str}" in
> python?.?)
> - dep_str="dev-lang/python:${dep_str: -3}" ;;
> + dep_str="dev-lang/python:${dep_str:
> -3}${_PYTHON_USE}" ;; jython?.?)
> - dep_str="dev-java/jython:${dep_str: -3}" ;;
> + dep_str="dev-java/jython:${dep_str:
> -3}${_JYTHON_USE}" ;; pypy?.?)
> - dep_str="dev-python/pypy:${dep_str: -3}" ;;
> + dep_str="dev-python/pypy:${dep_str:
> -3}${_PYPY_USE}" ;; *)
> die "Unsupported implementation: ${impl}" ;;
> esac
I have to think more about this.
Where are your use cases?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] RFC: python-distutils-ng.eclass - add a convenience variable for use deps
On Thu, 06 Sep 2012 16:42:27 -0400
Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> - -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
One signature is enough :P.
> On 06/09/12 04:26 PM, Michał Górny wrote:
> > Not that I'm that brilliant to come up with something good but it
> > should start with 'PYTHON_', I think, and be explanatory.
>
> I wanted it to be short -- this is a convenience variable to be used
> in *DEPEND; and since it contains Python Target Use Dependencies, i
> figured the acronym was the best way to go..
>
> PS, '@INTERNAL' is probably not a good tag to set here but i couldn't
> find documentation on what tags were available; if there's a @READONLY
> or @CONSTANT that would be best.
Try looking at the awk script in eclass-manpages/files.
> >> + +mysep= +PTUD= +for impl in ${PYTHON_COMPAT} ; do +
> >> PTUD+="${mysep}python_targets_${impl}?" + mysep="," +done +unset
> >> mysep +
> >
> > Nice hack with that mysep but I don't like it, sorry. I'd rather
> > avoid temporary variables here, or use a function and a 'local'
> > variable. Calling a function in global scope shouldn't be that
> > bad.
> >
> > or just something like:
> >
> > PTUD=${PYTHON_COMPAT// /?,}?
> >
>
> The 'for impl in ${PYTHON_COMPAT}' loop is actually run in global
> scope later, to set *DEPEND on each python implementation; i haven't
> checked but it's possible it can be done there.
Yes, that's a good idea to join loops. Bash is not a C compiler, he
won't do that for ya.
> Also, other bits are already using temp variables in global scope.
And others are also using facebook. Does that mean you really should be
like them?
> Also2, since this var needs to be substituted directly into atoms of
> the ebuild's *DEPEND, imo it needs to be in global scope as well
The variable yes, the mysep doesn't.
> > But then you would have to 'clean up' PYTHON_COMPAT first to avoid
> > non-space whitespace and so on.
> >
> >> EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test
> >> [Snip!]
> >>
> >> case "${EAPI}" in
> >
> > Er, that thing should go after EAPI check.
> >
>
> Could be, yes. I had thought to set it before the check as
> PYTHON_COMPAT itself is assigned (if unset) before the check.
Then it should be moved.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
[gentoo-dev] python-distutils-ng.eclass: allow useflag dependencies for python
I am missing a replacement for PYTHON_USE_WITH.
Would the attached patch help in any way? Review? Other ideas?
--- python-distutils-ng.eclass
+++ python-distutils-ng.eclass
@@ -59,6 +59,25 @@
# Set to any value to disable automatic reinstallation of scripts in bin
# directories. See python-distutils-ng_src_install function.
+# @ECLASS-VARIABLE: PYTHON_USE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# comma seperated list of useflags needed for python
+# this is directly substituted into dev-lang/python[${PYTHON_USE}] thus allowing
+# all valid useflag dependencies
+# example 1: PYTHON_USE="xml,sqlite"
+# example 2: PYTHON_USE="xml?,threads?,-foo"
+
+# @ECLASS-VARIABLE: JYTHON_USE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# same as PYTHON_USE just for JYTHON
+
+# @ECLASS-VARIABLE: PYPY_USE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# same as PYTHON_USE just for PYPY
+
EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test src_install
case "${EAPI}" in
@@ -107,16 +126,22 @@
fi
unset required_use_str
+# avoid empty use deps
+[[ -n ${PYTHON_USE} ]] && _PYTHON_USE="[${PYTHON_USE}]" || _PYTHON_USE=""
+[[ -n ${JYTHON_USE} ]] && _JYTHON_USE="[${JYTHON_USE}]" || _JYTHON_USE=""
+[[ -n ${PYPY_USE} ]] && _PYPY_USE="[${PYPY_USE}]" || _PYPY_USE=""
+
+# set python DEPEND and RDEPEND
for impl in ${PYTHON_COMPAT}; do
IUSE+=" python_targets_${impl}"
dep_str="${impl/_/.}"
case "${dep_str}" in
python?.?)
- dep_str="dev-lang/python:${dep_str: -3}" ;;
+ dep_str="dev-lang/python:${dep_str: -3}${_PYTHON_USE}" ;;
jython?.?)
- dep_str="dev-java/jython:${dep_str: -3}" ;;
+ dep_str="dev-java/jython:${dep_str: -3}${_JYTHON_USE}" ;;
pypy?.?)
- dep_str="dev-python/pypy:${dep_str: -3}" ;;
+ dep_str="dev-python/pypy:${dep_str: -3}${_PYPY_USE}" ;;
*)
die "Unsupported implementation: ${impl}" ;;
esac
Re: [gentoo-dev] RFC: python-distutils-ng.eclass - add a convenience variable for use deps
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/09/12 04:26 PM, Michał Górny wrote:
> On Thu, 06 Sep 2012 14:22:24 -0400 Ian Stakenvicius
> wrote:
>
>> So one of the advantages of using python-distutils-ng.eclass for
>> building (and building against) python modules is that python
>> module dependencies can be guaranteed against the same python
>> targets as what you're building for, via the PYTHON_TARGETS use
>> expansion.
>>
>> Unfortunately, one of the drawbacks to this is that dependencies
>> are long and ugly.
>>
>> Since in most cases, any python module in *DEPEND is going to
>> have python_targets_*? use deps for each implementation in
>> $PYTHON_COMPAT, a helper variable that can be substituted for
>> this list would simplify the ebuild.
>
> Didn't I think of the same thing some time ago?
>
Not sure; you think of so many different things.. :D
>> The implementation in the patch below is probably not the best,
>> but I propose it as a starting point.
>>
>>
>> - --- python-distutils-ng.eclass 2012-06-18 10:53:33.0
>> -0400 +++ python-distutils-ng.eclass.new 2012-09-06
>> 13:47:28.0 - -0400 @@ -59,6 +59,22 @@ # Set to any value
>> to disable automatic reinstallation of scripts in # bin
>> directories. See python-distutils-ng_src_install function.
>>
>> +# @ECLASS-VARIABLE: PTUD
>
> PTUD? Sounds like a verb. Something like 'you should PTUD yourself'
> ;D.
>
> Not that I'm that brilliant to come up with something good but it
> should start with 'PYTHON_', I think, and be explanatory.
>
I wanted it to be short -- this is a convenience variable to be used
in *DEPEND; and since it contains Python Target Use Dependencies, i
figured the acronym was the best way to go..
PS, '@INTERNAL' is probably not a good tag to set here but i couldn't
find documentation on what tags were available; if there's a @READONLY
or @CONSTANT that would be best.
>> +# @INTERNAL +# @DESCRIPTION: +# Provides the complete expansion
>> of python_target_ use depedencies +# from the content of
>> $PYTHON_COMPAT ; it can be used as a shortform +# to set or or
>> append the use deps of complete python-module +# dependencies,
>> ie: RDEPEND="dev-python/foo[${PTUD}]"
>
> I think it should spell clearer how the string looks like, i.e.
> that it is 'pythonx_y?,pythonx_z?,...'.
>
>> + +mysep= +PTUD= +for impl in ${PYTHON_COMPAT} ; do +
>> PTUD+="${mysep}python_targets_${impl}?" + mysep="," +done +unset
>> mysep +
>
> Nice hack with that mysep but I don't like it, sorry. I'd rather
> avoid temporary variables here, or use a function and a 'local'
> variable. Calling a function in global scope shouldn't be that
> bad.
>
> or just something like:
>
> PTUD=${PYTHON_COMPAT// /?,}?
>
The 'for impl in ${PYTHON_COMPAT}' loop is actually run in global
scope later, to set *DEPEND on each python implementation; i haven't
checked but it's possible it can be done there. Also, other bits are
already using temp variables in global scope. Also2, since this var
needs to be substituted directly into atoms of the ebuild's *DEPEND,
imo it needs to be in global scope as well
> But then you would have to 'clean up' PYTHON_COMPAT first to avoid
> non-space whitespace and so on.
>
>> EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test
>> [Snip!]
>>
>> case "${EAPI}" in
>
> Er, that thing should go after EAPI check.
>
Could be, yes. I had thought to set it before the check as
PYTHON_COMPAT itself is assigned (if unset) before the check.
- -BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlBJCTUACgkQ2ugaI38ACPD3TwEAj1rtDO1Rpbmf0g+nU+oHTj5Y
HIFVsn+bzbx+CB1xU5QBAKxXx5p33y4dhk03zM1VjRWM5J9QdC/uDGq42yapnfdd
=hm2B
- -END PGP SIGNATURE-
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlBJCrMACgkQ2ugaI38ACPAKsQD/VirFeTqL+ZdbGq0lgD8HuuyG
0YrQGw0i8CYN5eMdtpIBAIszTewkBVF75lWGull7MmWYfZkyYRPUI/b6JNnUO/o6
=fQvj
-END PGP SIGNATURE-
Re: [gentoo-dev] RFC: python-distutils-ng.eclass - add a convenience variable for use deps
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/09/12 04:26 PM, Michał Górny wrote:
Not sure; you think of so many different things.. :D
I wanted it to be short -- this is a convenience variable to be used
in *DEPEND; and since it contains Python Target Use Dependencies, i
figured the acronym was the best way to go..
PS, '@INTERNAL' is probably not a good tag to set here but i couldn't
find documentation on what tags were available; if there's a @READONLY
or @CONSTANT that would be best.
The 'for impl in ${PYTHON_COMPAT}' loop is actually run in global
scope later, to set *DEPEND on each python implementation; i haven't
checked but it's possible it can be done there. Also, other bits are
already using temp variables in global scope. Also2, since this var
needs to be substituted directly into atoms of the ebuild's *DEPEND,
imo it needs to be in global scope as well
Could be, yes. I had thought to set it before the check as
PYTHON_COMPAT itself is assigned (if unset) before the check.
- -BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlBJCTUACgkQ2ugaI38ACPD3TwEAj1rtDO1Rpbmf0g+nU+oHTj5Y
HIFVsn+bzbx+CB1xU5QBAKxXx5p33y4dhk03zM1VjRWM5J9QdC/uDGq42yapnfdd
=hm2B
- -END PGP SIGNATURE-
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlBJCrMACgkQ2ugaI38ACPAZjwD+PsGxG64rhKM5vmSO+g9Gc1Ij
N62tR4dar4zGlIGwwfUA/0JH62LPRO/sv6BsvAHWRfXuuU4tkYotY2m7yx5LF6sH
=Ff8b
-END PGP SIGNATURE-
Re: [gentoo-dev] RFC: python-distutils-ng.eclass - add a convenience variable for use deps
On Thu, 06 Sep 2012 14:22:24 -0400
Ian Stakenvicius wrote:
> So one of the advantages of using python-distutils-ng.eclass for
> building (and building against) python modules is that python module
> dependencies can be guaranteed against the same python targets as what
> you're building for, via the PYTHON_TARGETS use expansion.
>
> Unfortunately, one of the drawbacks to this is that dependencies are
> long and ugly.
>
> Since in most cases, any python module in *DEPEND is going to have
> python_targets_*? use deps for each implementation in $PYTHON_COMPAT,
> a helper variable that can be substituted for this list would simplify
> the ebuild.
Didn't I think of the same thing some time ago?
> The implementation in the patch below is probably not the best, but I
> propose it as a starting point.
>
>
> - --- python-distutils-ng.eclass 2012-06-18 10:53:33.0 -0400
> +++ python-distutils-ng.eclass.new 2012-09-06 13:47:28.0
> - -0400
> @@ -59,6 +59,22 @@
> # Set to any value to disable automatic reinstallation of scripts in
> # bin directories. See python-distutils-ng_src_install function.
>
> +# @ECLASS-VARIABLE: PTUD
PTUD? Sounds like a verb. Something like 'you should PTUD yourself' ;D.
Not that I'm that brilliant to come up with something good but it
should start with 'PYTHON_', I think, and be explanatory.
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Provides the complete expansion of python_target_ use depedencies
> +# from the content of $PYTHON_COMPAT ; it can be used as a shortform
> +# to set or or append the use deps of complete python-module
> +# dependencies, ie: RDEPEND="dev-python/foo[${PTUD}]"
I think it should spell clearer how the string looks like, i.e. that it
is 'pythonx_y?,pythonx_z?,...'.
> +
> +mysep=
> +PTUD=
> +for impl in ${PYTHON_COMPAT} ; do
> + PTUD+="${mysep}python_targets_${impl}?"
> + mysep=","
> +done
> +unset mysep
> +
Nice hack with that mysep but I don't like it, sorry. I'd rather avoid
temporary variables here, or use a function and a 'local' variable.
Calling a function in global scope shouldn't be that bad.
or just something like:
PTUD=${PYTHON_COMPAT// /?,}?
But then you would have to 'clean up' PYTHON_COMPAT first to avoid
non-space whitespace and so on.
> EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test
> [Snip!]
>
> case "${EAPI}" in
Er, that thing should go after EAPI check.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching
Yes. The manager can still parallelize prefetching, only consuming a build
job slot post fetch.
On Sep 6, 2012 11:49 AM, "Michał Górny" wrote:
> On Thu, 6 Sep 2012 09:49:13 -0700
> Brian Harring wrote:
>
> > One additional thought- re: the scenarios where we don't fetch to an
> > intermediate location, then transfer that contents into ${WORKDIR},
> > while a better name is needed, something along the lines of
> > RESTRICT=fetches-into-workdir comes to mind.
> >
> > Basically that restriction would be interpretted as "$WORKDIR must be
> > setup/preserved from invocation of src_fetch to actual building".
> >
> > Via that restrict, both scenarios should be addressed in full.
>
> Does separate src_fetch() provide any benefit in that scenario?
>
> --
> Best regards,
> Michał Górny
>
Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching
On Thu, 6 Sep 2012 09:49:13 -0700
Brian Harring wrote:
> One additional thought- re: the scenarios where we don't fetch to an
> intermediate location, then transfer that contents into ${WORKDIR},
> while a better name is needed, something along the lines of
> RESTRICT=fetches-into-workdir comes to mind.
>
> Basically that restriction would be interpretted as "$WORKDIR must be
> setup/preserved from invocation of src_fetch to actual building".
>
> Via that restrict, both scenarios should be addressed in full.
Does separate src_fetch() provide any benefit in that scenario?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
[gentoo-dev] RFC: python-distutils-ng.eclass - add a convenience variable for use deps
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hey all:
So one of the advantages of using python-distutils-ng.eclass for
building (and building against) python modules is that python module
dependencies can be guaranteed against the same python targets as what
you're building for, via the PYTHON_TARGETS use expansion.
Unfortunately, one of the drawbacks to this is that dependencies are
long and ugly.
Since in most cases, any python module in *DEPEND is going to have
python_targets_*? use deps for each implementation in $PYTHON_COMPAT,
a helper variable that can be substituted for this list would simplify
the ebuild.
The implementation in the patch below is probably not the best, but I
propose it as a starting point.
- --- python-distutils-ng.eclass 2012-06-18 10:53:33.0 -0400
+++ python-distutils-ng.eclass.new 2012-09-06 13:47:28.0
- -0400
@@ -59,6 +59,22 @@
# Set to any value to disable automatic reinstallation of scripts in
# bin directories. See python-distutils-ng_src_install function.
+# @ECLASS-VARIABLE: PTUD
+# @INTERNAL
+# @DESCRIPTION:
+# Provides the complete expansion of python_target_ use depedencies
+# from the content of $PYTHON_COMPAT ; it can be used as a shortform
+# to set or or append the use deps of complete python-module
+# dependencies, ie: RDEPEND="dev-python/foo[${PTUD}]"
+
+mysep=
+PTUD=
+for impl in ${PYTHON_COMPAT} ; do
+ PTUD+="${mysep}python_targets_${impl}?"
+ mysep=","
+done
+unset mysep
+
EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test [Snip!]
case "${EAPI}" in
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlBI6eAACgkQ2ugaI38ACPB4AgD5AbdrjfoQsn3Gf9eJSIOp7qQC
Ceu/TAaE8a+rDYoIG8QA/ivAVdNOBnzWi/VthlgkrXpkk1sQYV5hFWGcI2gVhygv
=cHPI
-END PGP SIGNATURE-
Re: [gentoo-dev] EAPI usage
On Thu, Sep 6, 2012 at 1:16 PM, Michael Orlitzky wrote: > From a developer's perspective, it's obviously better to be able to do > whatever you want. But for users it'd be nice to be able to request a > bump to EAPI5 and not get told to buzz off. It is easy. Don't ask for a bump to EAPI5. Ask for support for user patches, or whatever it is that you really need. I don't exactly see threads all over the place complaining about legitimate bugs being closed as WONTFIX. Rich
Re: [gentoo-dev] EAPI usage
On 09/05/2012 05:29 PM, Brian Harring wrote: > > Yes, I stated it because I view it as useful/sane. > >> and isn't a compromise at all. > > I think you're mistaken in assuming a compromise is the required > outcome of this. Given the choice between something productive, and > something not productive, you don't choose the quasi-productive > solution. >From a developer's perspective, it's obviously better to be able to do whatever you want. But for users it'd be nice to be able to request a bump to EAPI5 and not get told to buzz off. Some people are unhappy with the current situation or this thread wouldn't exist. A good compromise should make everyone just a little bit unhappy =)
Re: [gentoo-dev] EAPI usage
On Thu, Sep 6, 2012 at 1:03 PM, Michael Orlitzky wrote: > If there's really no reason, why would anyone bother to file a bug for > it? It's better for developers than the must-bump policy, and better for > users than what we have now. What change is even being proposed? If there is an issue that actually impacts users, then that issue is the bug, and bumping the EAPI is just the solution to the bug. If an ebuild unnecessarily ignores CFLAGS, or if it is a blocker to some eclass update, or whatever, then that is already considered a valid bug. That is my main concern with all of this stuff - just state what you need in terms of outcomes, not solutions. If you can't identify the outcome, then there is no need for the change anyway. By all means suggest solutions in the report, but don't confuse the solution with the problem. Rich
Re: [gentoo-dev] EAPI usage
On 09/05/2012 12:15 PM, Mike Gilbert wrote: > On Tue, Sep 4, 2012 at 9:03 PM, Michael Orlitzky wrote: >> On 09/04/2012 05:06 PM, Brian Harring wrote: As a compromise, it could be made policy that "bump to EAPI=foo" bugs are valid. If someone would benefit from such a bump, he can file a bug and know that it won't be closed WONTFIX. On the other hand, the dev is under no more pressure than usual to do the bump. >>> >>> If you attach a patch and have done the legwork, sure. >>> >>> If you're just opening bugs w/ "bump to EAPI=monkeys", bluntly, it's >>> noise and it's annoying. EAPI bump requests for pkgs that need to >>> move forward so an eclass can be cleaned up/moved forward, sure, but >>> arbitrary "please go bump xyz" without a specific reason (and/or >>> legwork done if not) isn't helpful. Kind of equivalent to zero-day >>> bump requests in my view in terms of usefulness. >> >> Except this is what we have now, and isn't a compromise at all. >> > > What use is a bug report requesting an EAPI bump for no reason? There > is no sense in "compromising" and creating such a policy if nobody > actually benefits from it. > If there's really no reason, why would anyone bother to file a bug for it? It's better for developers than the must-bump policy, and better for users than what we have now.
Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching
On Wed, Sep 05, 2012 at 12:07:22PM +0100, Ciaran McCreesh wrote:
> On Wed, 5 Sep 2012 13:00:05 +0200
> Micha?? G??rny wrote:
> > > I guess that's a pretty comprehensive "we need to do this properly"
> > > then.
> >
> > Did I say we don't need to? We have the two eclasses which need to do
> > this properly, right? So what's your problem?
>
> The problem is that we need to work out how to deal with this at least
> for Subversion, and probably for CVS too... As much as we'd like to, we
> can't just roll out a src_fetch without eclass changes. This doesn't
> appear to be a trivial feature to provide.
You're conflating the required phase/hook w/ existing bad
implementations; they're separate.
The bad implementations can't use the hook till they sort out their
mess; straight forward enough.
Worth noting, last I looked, git eclass actually didn't do this right
either; basically merges the namespace of each remote/fetch source
into the local namespace, no prefixing. Fixable, but the issue mostly
comes about because of the fact we do *not* have a src_fetch in the
first place.
Either way, if the hook was in place, I expect the eclass level issues
to be sorted shortly after; right now there isn't a reason to do that
work (chicken/egg).
Consider that my +1 for src_fetch also, although FDEPEND is needed or
dependencies; I don't care which, getting a src_fetch has been on my
todo for chrome-os for a while now.
One additional thought- re: the scenarios where we don't fetch to an
intermediate location, then transfer that contents into ${WORKDIR},
while a better name is needed, something along the lines of
RESTRICT=fetches-into-workdir comes to mind.
Basically that restriction would be interpretted as "$WORKDIR must be
setup/preserved from invocation of src_fetch to actual building".
Via that restrict, both scenarios should be addressed in full.
~harring
Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue
On 09/06/2012 02:01 AM, Fabian Groffen wrote: > After reading this thread, I have seen numerous occasions where has been > asked what this proposal actually solves. Unless I've accidentially > skipped over it, the answer has yet to be given. It appears to me now > sub-slot is a feature that makes it easy to express a situation that > could be expressed today as well, but requiring more work. As such > "syntactic sugar", it seems not well bounded, allowing possibly for > doing things that result in a big mess (I cannot prove this atm, and > there is no specification afaict.) The sub-slot is needed for those cases where it's just not practical to bump the regular slot. Tiziano Müller (dev-zero) has summarized the possible solutions well [1]: > I see four possibilities: > 1) patch them to version the headers as well and slot them (together with > slot operator deps) > 2) ask upstream to properly version the headers alongside with the lib and > slot them (together with slot operator deps) > 3) slot them and block old slots in newer versions (together with slot > operator deps) > 4) introduce a new EAPI variable which can be incremented whenever an soname > changes (needs some more thinking and proper specification, somehow > duplicates SLOT) Sub-slot implements #4 (by extending the SLOT variable instead of using a new variable). [1] https://bugs.gentoo.org/show_bug.cgi?id=414955#c10 -- Thanks, Zac
Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching
> "CM" == Ciaran McCreesh writes: CM> This doesn't work if we have, for example, foo:1 and foo:2 both using CM> the same SCM repository, but different branches. The subversion eclass already handles that; it stores in $distfiles/$P/$branch. The cvs eclass also could do so. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
[EDIT] Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/09/12 09:25 AM, Ian Stakenvicius wrote:
>
> sub-slots is the 'some-identifier' part of
> ${SLOT}/${some-identifier}. It doesn't have to *replate* to ${PV}
> at all, and generally shouldn't.
>
>
..i have no idea what "replate" was supposed to be. I think i meant
to type "equate"
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlBIpX4ACgkQ2ugaI38ACPC0jwD6A6PMqQHV/8sWZnqSm2hF/plD
iBrZRvAxH7T0YdjQKeMA/02YFiom8mHs0GUDKUe18PkzM5aBlGKbnYyYcwcD3eOO
=1cGg
-END PGP SIGNATURE-
Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/09/12 05:01 AM, Fabian Groffen wrote:
> Replying to this email since it seems to be the discussion behind
> the "sub-slot" feature proposed for EAPI 5.
>
> On 04-06-2012 23:26:18 +0200, Pacho Ramos wrote:
>> This is why I think we should try to push a bit my first
>> suggestion for the short term until "the perfect one" is ready
>> as, until then, we are having for years a problem that,
>> personally, I think it should be handled a bit better.
>
> After reading this thread, I have seen numerous occasions where has
> been asked what this proposal actually solves. Unless I've
> accidentially skipped over it, the answer has yet to be given. It
> appears to me now sub-slot is a feature that makes it easy to
> express a situation that could be expressed today as well, but
> requiring more work. As such "syntactic sugar", it seems not well
> bounded, allowing possibly for doing things that result in a big
> mess (I cannot prove this atm, and there is no specification
> afaict.)
>
#1 - there is both a specification, and an initial implementation, AND
a fork of the tree that is kept semi-up-to-date on my dev overlay. So
please test away. At present sub-slots have been set on Xorg
(automatically rebuilding x11-drivers/* on upgrades), and on perl
(automatically rebuilding everything (afaik) that perl-cleaner would
normally be needed for). There should be more than enough work done
on my portage fork for you to be able to experiment and prove/disprove
said mess.
#2 - related to your question about what the proposal solves -- in my
opinion, the biggest thing the proposal solves is the case where we
want the ability to use SLOTs in the tree to manage and track
dependency changes (ie, when an API or ABI has changed), but NOT allow
multiple versions of a package to be installed at the same time.
Further to this, it allows PMs to determine what needs to be rebuilt
due to the old (no longer existing) dep being supported prior to said
dep actually being removed.
> So, I'm looking for a specification what the components in the
> sub-slot exactly mean, and what behaviour they trigger. To me, it
> seems right now that sub-slot is simply ${SLOT}/${PV}, and some
> fancy sub-part matching (up to the '/' actually). It would be nice
> to have a sound and clear definition of that the SLOT value means,
> and what the sub-slot value means. How can one make it up? Could
> one also just start with 1 as sub-slot? Or use names?
> (SLOT="2/$(use fnord && echo fnord)"). I have no clue how to use
> this correctly, as well as what problems I should have that it
> solves.
sub-slots is the 'some-identifier' part of ${SLOT}/${some-identifier}.
It doesn't have to replate to ${PV} at all, and generally shouldn't.
More likely it should relate to the ${major}.${minor} in the main
library's SONAME. For non-libtool dependencies some other form of id
is used, ie for perl I used the major.minor from $PV.
>
> To clarify the last bit, could you please explain how the
> following situation benefits from sub-slot.
>
> Consider the packages libfnord, foo and bar. libfnord being a
> library, used by foo and bar, which are simple executables.
> libfnord has 6 versions (not necessarily all at the same time in
> the tree), with ELF soname and library versions:
>
> libfnord-1libfnord.so.3 libfnord.so.3.0 libfnord-2
> libfnord.so.5 libfnord.so.5.1 libfnord-2.1 libfnord.so.5
> libfnord.so.5.2 libfnord-2.1-r5 libfnord.so.5
> libfnord.so.5.2 libfnord-3libfnord.so.5
> libfnord.so.5.8 libfnord-3.5 libfnord.so.5
> libfnord.so.5.12
>
> Package foo and bar have the following versions and {,R}DEPEND:
>
> foo-3.0 >=libfnord-2 bar-1.234b=libfnord-1*
> bar-2.4 >=libfnord-3
>
> How would the SLOT and {,R}DEPEND values for these ebuilds look
> like, what happens when libfnord 2 and 3 are introduced in the
> tree, etc. Please show for both EAPI 4, EAPI 4+slot-deps and EAPI
> 4+sub-slot.
EAPI="4-slot-deps" is new to me; the implementation i've been testing
is EAPI="4-slot-abi" which is sub-slots and slot operators. This is
the spec that was written and proposed for EAPI=5 and so this is what
i'll use to describe the above.
First, assuming currently libfnord is SLOT=0, and that there are no
ABI/API breakages on libfnord-2 through libfnord-3.5, I would just use
the ${major} version from the SONAME for the sub-slot. IE:
libfnord-1:SLOT="0/3"
libfnord-2:SLOT="0/5"
libfnord-2.1:SLOT="0/5"
...
libfnord-3.5:SLOT="0/5"
And then, assuming that foo and bar both link in the usual way, IE
they link against libfnord.so.3 instead of just libfnord.so , they
both would RDEPEND as follows:
RDEPEND="app-cat/libfnord:="
> (numeric indicators added): [1]What if libfnord-2.1 or libfnord-3.5
> would be masked due to some problem not noticed prior to stabling
> that makes it useless for many users. [2]bar-2.4 during configure
> checks fo
Re: [gentoo-dev] relative ROOT: correct behavior when ROOT=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/09/12 03:55 AM, Ulrich Mueller wrote:
>> On Thu, 06 Sep 2012, Gregory M Turner wrote:
>
>> Hello, in my overlay I need to fix a bunch of issues that crop up
>> when implementing EPREFIX construction in scripts due to Cygwin's
>> idiosyncratic, but POSIX-compliant, handling of paths beginning
>> with "//" (Cygwin does some arguably pathological stuff when such
>> paths are used).
>
>> Almost all of these stem from the careless tacking of "ROOT" onto
>> "EPREFIX" in bash-scripts, i.e., as in this (made-up)
>> bash-script snippet:
>
>> ${ROOT:=/} EPREFIX="@GENTOO_PORTAGE_EPREFIX@"
>> EROOT="${ROOT}${EPREFIX}"
>
>> When ROOT is undefined or empty, this script will assign "//foo"
>> to EROOT and bad things will happen in Cygwin.
>
>> Several correct-ish solutions exist, i.e., in the above we could
>> change the concatenation statement to read:
>
>> EROOT="${ROOT}${EPREFIX#/}"
>
> I'd rather do it the other way around: EROOT=${ROOT%/}${EPREFIX}
>
> Reason: EPREFIX is guaranteed to start with a slash, whereas for
> ROOT I wouldn't be so sure that it always ends with one.
>
> Ulrich
>
Not to mention that `man 5 ebuild` specifically defines EROOT to be
"${ROOT%/}${EPREFIX}/" already , so all that's needed is the removal
of the final '/' if I'm reading this correctly..
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlBInW8ACgkQ2ugaI38ACPA0UQD/YePPvXa5wNhdvpk656RtwNwa
+yUJKdh/cdu2d8lKCcQA/2/SI4ApNEY/uAf0VxEyRKE6jxdm9/KM6a9gWfSJ0ttn
=gJ7i
-END PGP SIGNATURE-
Re: [gentoo-dev] relative ROOT: correct behavior when ROOT=
On 9/6/2012 12:55 AM, Ulrich Mueller wrote:
On Thu, 06 Sep 2012, Gregory M Turner wrote:
Several correct-ish solutions exist, i.e., in the above we could change
the concatenation statement to read:
EROOT="${ROOT}${EPREFIX#/}"
I'd rather do it the other way around:
EROOT=${ROOT%/}${EPREFIX}
Reason: EPREFIX is guaranteed to start with a slash, whereas for ROOT
I wouldn't be so sure that it always ends with one.
Good point, but EPREFIX is empty for non-prefix gentoo. So, I guess:
EROOT="${ROOT%/}/${EPREFIX#/}"
It's a contrived example anyhow, so it's mostly academic.
My main concern is the correct behavior when ROOT is defined, but empty
-- I mostly included this explanation to preempt anyone inclined to ask
"what are you trying to achieve?" :P
-gmt
Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue
Replying to this email since it seems to be the discussion behind
the "sub-slot" feature proposed for EAPI 5.
On 04-06-2012 23:26:18 +0200, Pacho Ramos wrote:
> This is why I think we should try to push a bit my first suggestion for
> the short term until "the perfect one" is ready as, until then, we are
> having for years a problem that, personally, I think it should be
> handled a bit better.
After reading this thread, I have seen numerous occasions where has been
asked what this proposal actually solves. Unless I've accidentially
skipped over it, the answer has yet to be given. It appears to me now
sub-slot is a feature that makes it easy to express a situation that
could be expressed today as well, but requiring more work. As such
"syntactic sugar", it seems not well bounded, allowing possibly for
doing things that result in a big mess (I cannot prove this atm, and
there is no specification afaict.)
So, I'm looking for a specification what the components in the sub-slot
exactly mean, and what behaviour they trigger. To me, it seems right
now that sub-slot is simply ${SLOT}/${PV}, and some fancy sub-part
matching (up to the '/' actually). It would be nice to have a sound and
clear definition of that the SLOT value means, and what the sub-slot
value means. How can one make it up? Could one also just start with 1
as sub-slot? Or use names? (SLOT="2/$(use fnord && echo fnord)"). I
have no clue how to use this correctly, as well as what problems I
should have that it solves.
To clarify the last bit, could you please explain how the following
situation benefits from sub-slot.
Consider the packages libfnord, foo and bar. libfnord being a library,
used by foo and bar, which are simple executables. libfnord has 6
versions (not necessarily all at the same time in the tree), with ELF
soname and library versions:
libfnord-1libfnord.so.3 libfnord.so.3.0
libfnord-2libfnord.so.5 libfnord.so.5.1
libfnord-2.1 libfnord.so.5 libfnord.so.5.2
libfnord-2.1-r5 libfnord.so.5 libfnord.so.5.2
libfnord-3libfnord.so.5 libfnord.so.5.8
libfnord-3.5 libfnord.so.5 libfnord.so.5.12
Package foo and bar have the following versions and {,R}DEPEND:
foo-3.0 >=libfnord-2
bar-1.234b=libfnord-1*
bar-2.4 >=libfnord-3
How would the SLOT and {,R}DEPEND values for these ebuilds look like,
what happens when libfnord 2 and 3 are introduced in the tree, etc.
Please show for both EAPI 4, EAPI 4+slot-deps and EAPI 4+sub-slot.
What if libfnord-2.1 or libfnord-3.5 would be masked due to some problem
not noticed prior to stabling that makes it useless for many users.
bar-2.4 during configure checks for a new function in libfnord-3.5 and
uses it if available, or uses an alternative code-path instead.
libfnord-2.1-r5 fixes a crash in some function of the library.
(Note: this whole example/question sounds like an ebuild-quiz question
that any dev should be able to answer then.)
What would be the advantage of sub-slot here, assuming the versioning of
the libraries follows ABI versioning rules defined by e.g. libtool.
Please enlighten me.
Fabian
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: Digital signature
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Thu, 6 Sep 2012 09:31:29 +0100 Ciaran McCreesh wrote: > On Thu, 6 Sep 2012 10:27:55 +0200 > Michał Górny wrote: > > But what I was saying is that I dislike the implicit 'no label == > > build+run'. It's unclear, very unclear. > > > > Why the heck: > > > > ( foo/bar ) > > > > introduces another label than: > > > > use? ( foo/bar ) > > > > ? > > Labels are propagated into child blocks, so it doesn't introduce a new > label. I think you've misunderstood something here... Right, too many ()s for me. Then my argument that I want us to require explicit label at start of global () still holds. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Thu, 6 Sep 2012 10:27:55 +0200 Michał Górny wrote: > But what I was saying is that I dislike the implicit 'no label == > build+run'. It's unclear, very unclear. > > Why the heck: > > ( foo/bar ) > > introduces another label than: > > use? ( foo/bar ) > > ? Labels are propagated into child blocks, so it doesn't introduce a new label. I think you've misunderstood something here... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Thu, 6 Sep 2012 09:00:40 +0100 Ciaran McCreesh wrote: > On Thu, 6 Sep 2012 09:39:25 +0200 > Michał Górny wrote: > > On Thu, 6 Sep 2012 06:58:51 +0100 > > Ciaran McCreesh wrote: > > > On Wed, 5 Sep 2012 18:15:43 +0200 > > > Michał Górny wrote: > > > > If we really want to go this route, then please at least require > > > > explicit label at start of DEPENDENCIES. And the same when > > > > appending to DEPENDENCIES -- just so 'unlikely' mistakes will > > > > leave us with hours of debugging. > > > > > > We should take the exheres-0 rules for labels and eclasses, which > > > limit labels' scopes to blocks, and which introduce an extra ( ) > > > block around the outside when doing eclass variable merging. > > > > Because? I believe we should take 'Gentoo rules', including required > > explicit build+run at the start. > > You mean, you want to invent some new rules that don't quite work, > rather than using the ones that do... The whole "initial labels" thing > isn't an issue for exheres-0, since rather than appending, the > resulting metadata variable ends up with extra ( ) blocks like this: > > ( > stuff/from-the-exheres > ) > ( > stuff/from-exlib-1 > ) > ( > stuff/from-exlib-2 > ) > > so there's no possibility of labels ending up applied to the wrong > thing. > > If you just append, you'd have to have some way of validating that > eclasses all individually specify an initial label. That's not > something that can easily be done. In that format there is not a single thing which *can be done easily*. But what I was saying is that I dislike the implicit 'no label == build+run'. It's unclear, very unclear. Why the heck: ( foo/bar ) introduces another label than: use? ( foo/bar ) ? > > > > Remember that this requirement will actually cause migration to > > > > EAPI 5 to be even harder than to any previous EAPIs. Migrating a > > > > single ebuild will require rewriting the dependencies, and > > > > migrating an eclass will require adding a lot of dirty code. > > > > > > Migrating to EAPI 5 requires rewriting dependencies anyway if > > > we're adding in HDEPEND. Also, earlier EAPIs have introduced new > > > phase functions, which is a far ickier change for ebuilds than > > > this. > > > > Do you really believe in HDEPEND in EAPI 5? I've already postponed > > this in my mind. Also, not every single ebuild will actually need > > it. > > *shrug* if all the new *DEPEND stuff ends up in EAPI 6, then there's > no point in DEPENDENCIES for EAPI 5. But we'll have to sort this out > sooner or later... Yes, there's more time for a meaningful discussion without switching everything upside-down just because you did it. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: PROPERTIES=funky-slots
On Mon, Sep 03, 2012 at 02:08:58PM +, Mark Bateman wrote: > Patrick Lauer gentoo.org> writes: > > > > > On 06/23/12 21:21, Ciaran McCreesh wrote: > > > There's been a move towards using slots for "clever" things that don't > > > fit the traditional way of how slots worked. Examples include the new > > > gtk2 / gtk3 handling and Ruby gems virtuals. > > > > > > Aside from being abusive, > > No, it solves a real problem. > > > this screws things up for Paludis users. > > -EDONTCARE, use a supported package manager > > > > So if the packagemanager is struggling to resolve whether a package belongs > in a > slot or not, would this be a case for encoding such metadata in the ebuild > filename. > > foo-slot2-3.2.1.ebuild > > This way the PM would be able to determine exactly what it has todo before it > starts to parse the ebuild No; the problem isn't getting the slot out of the metadata (moving it to the file name doesn't really do anything beyond make it slightly faster at the cost of being backwards incompatible for any existent PM that sees it); the problem is in the PMs resolver, and how it chooses to search the space. Basically, paludis does x, the rest do y; funky-slots was intended to make 'x' behave better at the cost of ebuild devs having to go mark shit up (leading to the retort 'do y instead'). ~harring
Re: [gentoo-dev] supporting static-libs
On Mon, Sep 03, 2012 at 10:54:15PM +0200, Maciej Mrozowski wrote: > On Tuesday 28 of August 2012 02:15:40 hasufell wrote: > > Is there a reason not to support static-libs in an ebuild if the package > > supports it? > > > > It seems some developers don't care about this option. What's the gentoo > > policy on this? Isn't this actually a bug? > > A little remark. > For CMake controlled buildsystem (as you're coming here from latest dev- > games/simgear), there's no automatic way of building both static and shared > libs (simgear allows to choose just one). > This is why I removed static libs support that you proposed for dev- > games/simgear (similar to ruby eclass abi handling - manually calling phases > twice to build package 1st as shared, 2nd time as static). > This is what I called "not worth the effort" in private discussion with you, > not quite "I don't care for static libs" :) Guessing in the worst case, you can do a double compile to get around this, no? And yes, that's freaking horrible, just verifying cmake isn't doing something special that blocks it. Is upstream doing anything about this, or is it not on their radar/list-of-things-they-care-about ? ~harring
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Wed, Sep 05, 2012 at 12:06:45AM +, Jorge Manuel B. S. Vicetto wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 31-08-2012 20:46, Ciaran McCreesh wrote:
>
>
>
> > Also, we're getting rather a lot of *DEPEND variables here... If
> > we're making people make major changes to their deps, which for
> > HDEPEND we definitely would be, then the "it's expensive since
> > people would have to redo their deps" argument against a combined
> > DEPENDENCIES variable goes out of the window, so we should rethink
> > that too.
>
> I have to agree with Ciaran, instead of multiplying DEPEND variables,
> it's probably time we move to a single DEPENDENCIES variable.
Personally, my complaints re: it are that 1) while minor, the
labels in some cases are overly verbose; recommendations instead of
recommends, suggestions instead of suggests, etc. 2) An actual
flaw in their design (imo): it tries to intermix two different
forms of parsing, without any real justification for *why* beyond
*hey look kids, I can!*; The two can intersect in slightly fucked
up ways, case in point:
DEPENDENCIES="
run+build:
cat/the
x? ( cat/cow
test:
y? ( cat/says
z? ( cat/moo
)))
Now, there may be some unstated rules that disallow that, but if that
*is* allowed, that's frankly dumb. As to if it's disallowed, it's
kind of a design flaw that the situation can occur requiring an
explicit suppression.
Rather than invent and try intermixing a secondary form, just using
the existing strikes me as saner; either we can have a specific
use_expand group like thus:
DEPENDENCIES="
dep_run? ( cat/monkeys )
dep_run+build? ( cat/foo )"
Or, preferable imo, do away w/ the +, use a more natural ',' for phase
separation, and use ':';
DEPENDENCIES="
dep:run? ( cat/monkeys )
dep:run,build? ( cat/foo )"
Doing it that way reuses the existing parsing infrastructure (good)
via just requiring a change to the use validation machinery (easy if
the PM is implemented sanely).
It also is able to express things that exheres variation can't do as
cleanly; considering build/fetch/post/run/test as the viable dep
targets:
DEPENDENCIES="
build+fetch+post+test:
some-dep"
vs
DEPENDENCIES="!dep:run? ( some-dep )"
I don't much expect that to occur, but the potential exists, thus
mentioning it.
One unstated fault re: DEPENDENCIES btw, is it will not play nice w/
exactly one of blocks. Treating '^^' as "exactly one of", consider:
DEPENDENCIES="
^^ (
run:
cat/blah
build:
cat/dar
cat/foon
)"
Is that a stupid dep? You bet your ass it is.. But it would have to
be explicitly suppressed by the parser for any such construct- moreso,
repoman would have to spot it which is slightly unfun.
Finally, one note; while certain folk have been making lots of noise
about DEPENDENCIES being the best thing since sliced bread, their
isn't much comment about how one actually transitions to it without
making eclass authors who have to support both pre-DEPENDENCIES, and
post-DEPENDENCIES eapis happy; kind of swiss cheeses the hell out of
the code frankly.
A compatibility hack that stacks them is strongly advisable; something
akin to the following:
Literally, we do the following:
inherit() {
if eapi blah; then
local DEPEND PDEPEND RDEPEND
else
fi
if eapi blah; then
local _deps=( ) _x
for _x in DEPENDENCIES DEPEND RDEPEND PDEPEND; do
[ -n "${!_x}" ] && deps+=( "${!_x}" )
done
[ ${#deps} -ne 0 ] && DEPENDENCIES="${deps[*]}"
unset DEPEND RDEPEND PDEPEND _x _deps
else
fi
}
Via that, we eclasses that are pure DEPENDENCIES eapi wise, just set
the DEPENDENCIES directly; those that have to support multiple eapi's
(aka, every fricking eclass that exists right now) can just use the
old form, shifting into the new form as things progress.
Either way, the dual parsing required for exheres version I'm -1 on;
I'm generally wary of NIH modifications, but the form I've mentioned
that reuses our existing machinery is +.5...ish... from my standpoint
(+1 on the form, just kind of 'meh' on the single var angle despite
mostly agreeing w/ the reasoning).
Either way, on w/ the flaming/insinuations of
idiocy/counter-insinuations of being a wee bit too friendly w/
sheep...
~harring
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Thu, 6 Sep 2012 09:39:25 +0200 Michał Górny wrote: > On Thu, 6 Sep 2012 06:58:51 +0100 > Ciaran McCreesh wrote: > > On Wed, 5 Sep 2012 18:15:43 +0200 > > Michał Górny wrote: > > > If we really want to go this route, then please at least require > > > explicit label at start of DEPENDENCIES. And the same when > > > appending to DEPENDENCIES -- just so 'unlikely' mistakes will > > > leave us with hours of debugging. > > > > We should take the exheres-0 rules for labels and eclasses, which > > limit labels' scopes to blocks, and which introduce an extra ( ) > > block around the outside when doing eclass variable merging. > > Because? I believe we should take 'Gentoo rules', including required > explicit build+run at the start. You mean, you want to invent some new rules that don't quite work, rather than using the ones that do... The whole "initial labels" thing isn't an issue for exheres-0, since rather than appending, the resulting metadata variable ends up with extra ( ) blocks like this: ( stuff/from-the-exheres ) ( stuff/from-exlib-1 ) ( stuff/from-exlib-2 ) so there's no possibility of labels ending up applied to the wrong thing. If you just append, you'd have to have some way of validating that eclasses all individually specify an initial label. That's not something that can easily be done. > > (And I have a sneaking recollection of PMS not documenting this > > properly...) > > Yes, I think PMS is pretty silent about this. I think it doesn't even > say that in phase functions the contents are implementation-defined. That's covered under the general rules for environment variables. The issue is that PMS doesn't make a good distinction between the metadata variable's value and the environment variable value. The wording that's in there currently dates back to how things worked a very long time ago. > > > Remember that this requirement will actually cause migration to > > > EAPI 5 to be even harder than to any previous EAPIs. Migrating a > > > single ebuild will require rewriting the dependencies, and > > > migrating an eclass will require adding a lot of dirty code. > > > > Migrating to EAPI 5 requires rewriting dependencies anyway if we're > > adding in HDEPEND. Also, earlier EAPIs have introduced new phase > > functions, which is a far ickier change for ebuilds than this. > > Do you really believe in HDEPEND in EAPI 5? I've already postponed > this in my mind. Also, not every single ebuild will actually need it. *shrug* if all the new *DEPEND stuff ends up in EAPI 6, then there's no point in DEPENDENCIES for EAPI 5. But we'll have to sort this out sooner or later... > > > And we will have to convert them back to old-style dependencies > > > anyway. For the sake of compatibility with external tools. > > > > No, external tools are required to be EAPI aware. If they're not, > > then the external tools need fixing. > > Changing package manager API like that between EAPI is just bad. You > know that, don't you? Your choices are to make the package manager API abstract out this sort of thing, or to require client updates for a new EAPI. And as it's fairly hard to predict what's going to be in a new EAPI, being too abstract is pretty much a lost cause. You can't simply convert new concepts to old concepts, since there's no pre-EAPI-5 concept of what any of these new dependency types are. Treating an HDEPEND or an IDEPEND as a DEPEND is just wrong. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] relative ROOT: correct behavior when ROOT=
> On Thu, 06 Sep 2012, Gregory M Turner wrote:
> Hello, in my overlay I need to fix a bunch of issues that crop up when
> implementing EPREFIX construction in scripts due to Cygwin's
> idiosyncratic, but POSIX-compliant, handling of paths beginning with
> "//" (Cygwin does some arguably pathological stuff when such paths are
> used).
> Almost all of these stem from the careless tacking of "ROOT" onto
> "EPREFIX" in bash-scripts, i.e., as in this (made-up) bash-script snippet:
> ${ROOT:=/}
> EPREFIX="@GENTOO_PORTAGE_EPREFIX@"
> EROOT="${ROOT}${EPREFIX}"
> When ROOT is undefined or empty, this script will assign "//foo" to
> EROOT and bad things will happen in Cygwin.
> Several correct-ish solutions exist, i.e., in the above we could change
> the concatenation statement to read:
> EROOT="${ROOT}${EPREFIX#/}"
I'd rather do it the other way around:
EROOT=${ROOT%/}${EPREFIX}
Reason: EPREFIX is guaranteed to start with a slash, whereas for ROOT
I wouldn't be so sure that it always ends with one.
Ulrich
[gentoo-dev] relative ROOT: correct behavior when ROOT=
Hello, in my overlay I need to fix a bunch of issues that crop up when
implementing EPREFIX construction in scripts due to Cygwin's
idiosyncratic, but POSIX-compliant, handling of paths beginning with
"//" (Cygwin does some arguably pathological stuff when such paths are
used).
Almost all of these stem from the careless tacking of "ROOT" onto
"EPREFIX" in bash-scripts, i.e., as in this (made-up) bash-script snippet:
${ROOT:=/}
EPREFIX="@GENTOO_PORTAGE_EPREFIX@"
EROOT="${ROOT}${EPREFIX}"
When ROOT is undefined or empty, this script will assign "//foo" to
EROOT and bad things will happen in Cygwin.
Several correct-ish solutions exist, i.e., in the above we could change
the concatenation statement to read:
EROOT="${ROOT}${EPREFIX#/}"
Thats a matter for another thread, however.
As I've been reading code like the above, I've stumbled across some bugs
and inconsistencies pertaining to relative-ROOT and I've been trying to
file bugs to get these fixed.
One such issue pertains to the case where the ROOT environment variable
is defined, but empty. Portage and most python code seem to treat this
as equivalent to ROOT="${PWD}", which is to say, that relative-root
functionality is triggered by this circumstance.
However, several app-admin and sys-devel scripts "disagree" and treat
this as equivalent to ROOT="/" (as does my example above).
So... which behavior is correct? Since I'm aware of the issue, I'd
might as well file bugs against the incorrect ones and get everything
consistent.
-gmt
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Thu, 6 Sep 2012 06:58:51 +0100 Ciaran McCreesh wrote: > On Wed, 5 Sep 2012 18:15:43 +0200 > Michał Górny wrote: > > If we really want to go this route, then please at least require > > explicit label at start of DEPENDENCIES. And the same when appending > > to DEPENDENCIES -- just so 'unlikely' mistakes will leave us with > > hours of debugging. > > We should take the exheres-0 rules for labels and eclasses, which > limit labels' scopes to blocks, and which introduce an extra ( ) > block around the outside when doing eclass variable merging. Because? I believe we should take 'Gentoo rules', including required explicit build+run at the start. > > Not that appending dependencies in eclasses is really that good > > idea. > > Dependencies aren't appended over eclasses, they're merged. Thanks for correcting my wording, like the naming was really relevant to the topic. > (And I have a sneaking recollection of PMS not documenting this > properly...) Yes, I think PMS is pretty silent about this. I think it doesn't even say that in phase functions the contents are implementation-defined. > > Remember that this requirement will actually cause migration to > > EAPI 5 to be even harder than to any previous EAPIs. Migrating a > > single ebuild will require rewriting the dependencies, and > > migrating an eclass will require adding a lot of dirty code. > > Migrating to EAPI 5 requires rewriting dependencies anyway if we're > adding in HDEPEND. Also, earlier EAPIs have introduced new phase > functions, which is a far ickier change for ebuilds than this. Do you really believe in HDEPEND in EAPI 5? I've already postponed this in my mind. Also, not every single ebuild will actually need it. > > And we will have to convert them back to old-style dependencies > > anyway. For the sake of compatibility with external tools. > > No, external tools are required to be EAPI aware. If they're not, then > the external tools need fixing. Changing package manager API like that between EAPI is just bad. You know that, don't you? -- Best regards, Michał Górny signature.asc Description: PGP signature
