Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
El vie, 21-09-2012 a las 21:01 +0200, Pacho Ramos escribió: El jue, 20-09-2012 a las 14:23 -0400, Ian Stakenvicius escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/09/12 02:12 PM, Michael Mol wrote: On Thu, Sep 20, 2012 at 1:58 PM, Pacho Ramos pa...@gentoo.org wrote: El jue, 20-09-2012 a las 10:14 -0400, Ian Stakenvicius escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/09/12 09:52 AM, Ciaran McCreesh wrote: On Thu, 20 Sep 2012 09:13:40 -0400 Ian Stakenvicius a...@gentoo.org wrote: PMS may not need to be fixed, just the spec PMS is the spec, and it doesn't need fixing, since it accurately reflects the situation we're dealing with. Sorry, I misread PMS as PMs (portage, paludis, etc). And, for support to be official for ebuilds or eclasses to query IUSE (or other globals) within phase functions, then the 'spec' (PMS) is probably all that needs to be 'fixed'. Right? So, in EAPI=6, we propose something that'll make it official (ie a querying function; or ensure that PMs can provide these variables along with their proper 'effective' values, or their in-ebuild 'explicit' values, or whatever it is we want to say can be relied upon, to the environment). The problem of waiting for eapi6 to specify CURRENT behavior is that we don't know how much time will need to wait until it's approved (as I think eapi5 cannot include this extra function as was approved some hours ago). Other option would be to fast release some kind of eapi5.1 adding this... but, again, I think we are discussing about something that could be resolved as simply as specifying current behavior for all existing eapis (as we are in fact doing in the tree) and rely on new eapis for future hypothetical changes on it. The key question is: How would you formally describe the current behavior? I think someone already noted it's not reliable behavior in all places. I think we'd need an audit of what current behaviour is and then define based on that. Possibly removing cases where the 'expected' behaviour isn't occurring (ie, bugs that just aren't being caught). I'm biased, so to me just auditing what portage does would be good enough. :D But probably the other PMs should be audited to before 'official' behaviour should be described for PMS. Will ask to portage people then to know what is current behavior Here it's: http://www.mail-archive.com/gentoo-portage-dev@lists.gentoo.org/msg02830.html signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
El jue, 20-09-2012 a las 14:23 -0400, Ian Stakenvicius escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/09/12 02:12 PM, Michael Mol wrote: On Thu, Sep 20, 2012 at 1:58 PM, Pacho Ramos pa...@gentoo.org wrote: El jue, 20-09-2012 a las 10:14 -0400, Ian Stakenvicius escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/09/12 09:52 AM, Ciaran McCreesh wrote: On Thu, 20 Sep 2012 09:13:40 -0400 Ian Stakenvicius a...@gentoo.org wrote: PMS may not need to be fixed, just the spec PMS is the spec, and it doesn't need fixing, since it accurately reflects the situation we're dealing with. Sorry, I misread PMS as PMs (portage, paludis, etc). And, for support to be official for ebuilds or eclasses to query IUSE (or other globals) within phase functions, then the 'spec' (PMS) is probably all that needs to be 'fixed'. Right? So, in EAPI=6, we propose something that'll make it official (ie a querying function; or ensure that PMs can provide these variables along with their proper 'effective' values, or their in-ebuild 'explicit' values, or whatever it is we want to say can be relied upon, to the environment). The problem of waiting for eapi6 to specify CURRENT behavior is that we don't know how much time will need to wait until it's approved (as I think eapi5 cannot include this extra function as was approved some hours ago). Other option would be to fast release some kind of eapi5.1 adding this... but, again, I think we are discussing about something that could be resolved as simply as specifying current behavior for all existing eapis (as we are in fact doing in the tree) and rely on new eapis for future hypothetical changes on it. The key question is: How would you formally describe the current behavior? I think someone already noted it's not reliable behavior in all places. I think we'd need an audit of what current behaviour is and then define based on that. Possibly removing cases where the 'expected' behaviour isn't occurring (ie, bugs that just aren't being caught). I'm biased, so to me just auditing what portage does would be good enough. :D But probably the other PMs should be audited to before 'official' behaviour should be described for PMS. Will ask to portage people then to know what is current behavior signature.asc Description: This is a digitally signed message part
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
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Thu, 20 Sep 2012 08:43:11 +0200 Pacho Ramos pa...@gentoo.org wrote: 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. Well, it works and people use it, so it's better to keep a good function rather than rely on people remembering to handle all stripping and splitting correctly. I wanted to propose fixing PMS but, as you can see, there are mysterious broken systems which nobody has ever seen but surely exist somewhere and Ciaran won't waste his time telling us where in his imagination it is, and thus we can't simply fix it. -- 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 08:43:11 +0200 Pacho Ramos pa...@gentoo.org wrote: 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? We had this discussion when the function was introduced. It's supposed to be used for cosmetic things only. -- Ciaran McCreesh 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 20/09/12 03:41 AM, Michał Górny wrote: On Thu, 20 Sep 2012 08:43:11 +0200 Pacho Ramos pa...@gentoo.org wrote: 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. Well, it works and people use it, so it's better to keep a good function rather than rely on people remembering to handle all stripping and splitting correctly. I wanted to propose fixing PMS but, as you can see, there are mysterious broken systems which nobody has ever seen but surely exist somewhere and Ciaran won't waste his time telling us where in his imagination it is, and thus we can't simply fix it. PMS may not need to be fixed, just the spec -- ie, (if I'm understanding Ciaran properly), as long as the spec says that the effective IUSE (or other globals) is available for access (via function getter or however) during phase functions, then PMS will have to guarantee it to be there. Right now they don't, and so even if it works we can't rely on it working because said functionality might break in the course of regular portage/other PMS development (and doesn't need to be fixed because to date it's not in the spec). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBbFoQACgkQ2ugaI38ACPCWIAEAkDBX6zRm9uAygFTAoNuVKPEq Weq2eFQATLdYjUQ1HhoA/0dG89SayOG3gjSefG92A62H+EeBARQpPpa/xxAqoESi =hhU4 -END PGP SIGNATURE-
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 20 Sep 2012 09:13:40 -0400 Ian Stakenvicius a...@gentoo.org wrote: PMS may not need to be fixed, just the spec PMS is the spec, and it doesn't need fixing, since it accurately reflects the situation we're dealing with. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlBbH48ACgkQ96zL6DUtXhEfFACfebA7J5jLGhxs3wJoW62juu1j 4GEAoMgcNjRGVxN7Dvfph6lnETsuXUIR =Uud8 -END PGP SIGNATURE-
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/09/12 09:52 AM, Ciaran McCreesh wrote: On Thu, 20 Sep 2012 09:13:40 -0400 Ian Stakenvicius a...@gentoo.org wrote: PMS may not need to be fixed, just the spec PMS is the spec, and it doesn't need fixing, since it accurately reflects the situation we're dealing with. Sorry, I misread PMS as PMs (portage, paludis, etc). And, for support to be official for ebuilds or eclasses to query IUSE (or other globals) within phase functions, then the 'spec' (PMS) is probably all that needs to be 'fixed'. Right? So, in EAPI=6, we propose something that'll make it official (ie a querying function; or ensure that PMs can provide these variables along with their proper 'effective' values, or their in-ebuild 'explicit' values, or whatever it is we want to say can be relied upon, to the environment). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBbJMgACgkQ2ugaI38ACPAlMQD+N9OqgJN8+LR7mir9my5Z7t/9 /3VzJvgozs47ybh3ZrUA/R6rca5Ts/lEn2FWVOpqcK9ajyD8pa9wHaKTzEXpq2+v =F0jI -END PGP SIGNATURE-
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 20 Sep 2012 10:14:32 -0400 Ian Stakenvicius a...@gentoo.org wrote: And, for support to be official for ebuilds or eclasses to query IUSE (or other globals) within phase functions, then the 'spec' (PMS) is probably all that needs to be 'fixed'. Right? First someone would have to check very very carefully that it's now supported everywhere, including when using binaries, when doing VDB loading, etc. We'd also have to make sure we're not going to be hit by bash changing the behaviour of 'source' again... So, in EAPI=6, we propose something that'll make it official (ie a querying function; or ensure that PMs can provide these variables along with their proper 'effective' values, or their in-ebuild 'explicit' values, or whatever it is we want to say can be relied upon, to the environment). You'll have to be very very specific about where it will and won't work. It definitely won't work everywhere in global scope, for example. There's also the question of whether we effectively want to force merging and normalising of variables to be done on the bash side, rather than inside the package mangler. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlBbJ5IACgkQ96zL6DUtXhFA7wCcDnPCizqcqFImdkjSqcG599wU PygAn2W/8qX9tjgQUYM1KXhcUeCnpCcK =7kyg -END PGP SIGNATURE-
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 20/09/12 10:26 AM, Ciaran McCreesh wrote:
On Thu, 20 Sep 2012 10:14:32 -0400 Ian Stakenvicius
a...@gentoo.org wrote:
And, for support to be official for ebuilds or eclasses to query
IUSE (or other globals) within phase functions, then the 'spec'
(PMS) is probably all that needs to be 'fixed'. Right?
First someone would have to check very very carefully that it's
now supported everywhere, including when using binaries, when doing
VDB loading, etc. We'd also have to make sure we're not going to be
hit by bash changing the behaviour of 'source' again...
So, in EAPI=6, we propose something that'll make it official (ie
a querying function; or ensure that PMs can provide these
variables along with their proper 'effective' values, or their
in-ebuild 'explicit' values, or whatever it is we want to say can
be relied upon, to the environment).
You'll have to be very very specific about where it will and won't
work. It definitely won't work everywhere in global scope, for
example.
There's also the question of whether we effectively want to force
merging and normalising of variables to be done on the bash side,
rather than inside the package mangler.
*nod*
I'm not tied to a particular implementation, rather just that the
values of some of these global vars (IUSE, for instance) do seem to
have a need to be available for querying during phase functions (and
PMS will need to be updated to make this legal, via i assume a future
EAPI)
That said, since some vars are and must be made available from global
scope (ie, ${S}), I expect that it shouldn't be difficult to enforce
effective ${IUSE} no matter what possible things bash might change.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlBbKswACgkQ2ugaI38ACPBAQAD/YwjnXJGgLTQ0Fhcv6XpHkCAc
HokQhnN9i2Mu1aYikZcA/2bKlBCnVaPkjB7bQu1S+1BM8MAlmUi410IdYyYMldjn
=Fp3a
-END PGP SIGNATURE-
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
El jue, 20-09-2012 a las 03:33 -0400, Alexandre Rostovtsev escribió: On Thu, 2012-09-20 at 08:43 +0200, Pacho Ramos wrote: 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. A fair number of existing eclasses and ebuilds rely on being able to read IUSE, whether directly or via in_iuse/use_if_iuse, so it evidently works with current versions of portage and bash (otherwise users would be complaining). But technically, these ebuilds/eclasses are relying on unspecified behavior. There is no immediate pressure to change them - after all, they work fine at the moment, and in the case of ebuilds, avoiding IUSE would probably require changes to the ebuild's API. The problem is that I suspect that, maybe, this behavior was present and supported even in eapi0 (when, if I don't misremember, portage behavior was taken with small modifications as start point for newer eapis) then, maybe, this is simply a problem of forgetting to document this behavior that looks to work and be supported for all EAPIs for ages, making the need of waiting for eapi6 to use this useless and a nonsense. But given that we are already making a change to vala_src_prepare's default behavior, it makes sense to ensure that the change in a way that respects the pms. Although it will almost certainly provide no practical benefits, it is still good style. The problem is that there is no gain as it moves from autodetecting USE to need to manually review ebuild and add another variable to specify it manually :|, it clearly has cons over using automatic way to fix an unspecified behavior that could be fixed simply specifying it as that behavior is there for ages, is used in the tree for a long time and we are already relying on it for many eclasses/ebuilds. The other option would be to move all of them to another way alternative way to, once eapi6 is approved, revert them to previous situation, causing us to lose a lot of time with no gain. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
El jue, 20-09-2012 a las 09:13 -0400, Ian Stakenvicius escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/09/12 03:41 AM, Michał Górny wrote: On Thu, 20 Sep 2012 08:43:11 +0200 Pacho Ramos pa...@gentoo.org wrote: 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. Well, it works and people use it, so it's better to keep a good function rather than rely on people remembering to handle all stripping and splitting correctly. I wanted to propose fixing PMS but, as you can see, there are mysterious broken systems which nobody has ever seen but surely exist somewhere and Ciaran won't waste his time telling us where in his imagination it is, and thus we can't simply fix it. PMS may not need to be fixed, just the spec -- ie, (if I'm understanding Ciaran properly), as long as the spec says that the effective IUSE (or other globals) is available for access (via function getter or however) during phase functions, then PMS will have to guarantee it to be there. Right now they don't, and so even if it works we can't rely on it working because said functionality might break in the course of regular portage/other PMS development (and doesn't need to be fixed because to date it's not in the spec). That isn't necessary what could occur if the behavior changes unexpectedly: as current behavior is already being assumed in eclasses/ebuilds, portage couldn't change it without, before, porting ebuilds/eclasses to use that new hypothetical behavior. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
El jue, 20-09-2012 a las 14:52 +0100, Ciaran McCreesh escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 20 Sep 2012 09:13:40 -0400 Ian Stakenvicius a...@gentoo.org wrote: PMS may not need to be fixed, just the spec PMS is the spec, and it doesn't need fixing, since it accurately reflects the situation we're dealing with. - -- Ciaran McCreesh What is preventing us from specifying current behavior in PMS? Current behavior is already working for ages and being used in the tree for a long time, then, the clear way to go is to document it and, if it needs to change in the future, specify new behavior on a newer eapi. It's the simplest solution, it should work, would prevent us from need to move current eclasses/ebuilds to worse ways of handling this to later revert that work. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Thu, 20 Sep 2012 19:52:11 +0200 Pacho Ramos pa...@gentoo.org wrote: The problem is that I suspect that, maybe, this behavior was present and supported even in eapi0 It wasn't. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Thu, 20 Sep 2012 19:54:43 +0200 Pacho Ramos pa...@gentoo.org wrote: That isn't necessary what could occur if the behavior changes unexpectedly: as current behavior is already being assumed in eclasses/ebuilds, portage couldn't change it without, before, porting ebuilds/eclasses to use that new hypothetical behavior. Sure it can. Portage supports what's in the spec. If you're relying upon undefined behaviour, it's your problem when it stops working. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
El jue, 20-09-2012 a las 10:14 -0400, Ian Stakenvicius escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/09/12 09:52 AM, Ciaran McCreesh wrote: On Thu, 20 Sep 2012 09:13:40 -0400 Ian Stakenvicius a...@gentoo.org wrote: PMS may not need to be fixed, just the spec PMS is the spec, and it doesn't need fixing, since it accurately reflects the situation we're dealing with. Sorry, I misread PMS as PMs (portage, paludis, etc). And, for support to be official for ebuilds or eclasses to query IUSE (or other globals) within phase functions, then the 'spec' (PMS) is probably all that needs to be 'fixed'. Right? So, in EAPI=6, we propose something that'll make it official (ie a querying function; or ensure that PMs can provide these variables along with their proper 'effective' values, or their in-ebuild 'explicit' values, or whatever it is we want to say can be relied upon, to the environment). The problem of waiting for eapi6 to specify CURRENT behavior is that we don't know how much time will need to wait until it's approved (as I think eapi5 cannot include this extra function as was approved some hours ago). Other option would be to fast release some kind of eapi5.1 adding this... but, again, I think we are discussing about something that could be resolved as simply as specifying current behavior for all existing eapis (as we are in fact doing in the tree) and rely on new eapis for future hypothetical changes on it. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
El jue, 20-09-2012 a las 09:10 +0100, Ciaran McCreesh escribió: On Thu, 20 Sep 2012 08:43:11 +0200 Pacho Ramos pa...@gentoo.org wrote: 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? We had this discussion when the function was introduced. It's supposed to be used for cosmetic things only. What are cosmetics things? Also, what do you mean by It's supposed? Who should decide what is supposed and what not? From past discussions I remember somebody remembered me that, when you talk here, you are simply talking as another one subscribed here, like me and others, you don't represent PMS team and have no special rule to forbid us what to do, that is the reason why I asked for more opinions about how to handle this situation in the tree and why I demanded Alexandre to wait a bit before commiting second way because that way simply adds more complication with no benefit apart of address your complaints even leaving the rest of the tree (ebuilds/eclasses already using it) unchanged. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Thu, Sep 20, 2012 at 1:58 PM, Pacho Ramos pa...@gentoo.org wrote: El jue, 20-09-2012 a las 10:14 -0400, Ian Stakenvicius escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/09/12 09:52 AM, Ciaran McCreesh wrote: On Thu, 20 Sep 2012 09:13:40 -0400 Ian Stakenvicius a...@gentoo.org wrote: PMS may not need to be fixed, just the spec PMS is the spec, and it doesn't need fixing, since it accurately reflects the situation we're dealing with. Sorry, I misread PMS as PMs (portage, paludis, etc). And, for support to be official for ebuilds or eclasses to query IUSE (or other globals) within phase functions, then the 'spec' (PMS) is probably all that needs to be 'fixed'. Right? So, in EAPI=6, we propose something that'll make it official (ie a querying function; or ensure that PMs can provide these variables along with their proper 'effective' values, or their in-ebuild 'explicit' values, or whatever it is we want to say can be relied upon, to the environment). The problem of waiting for eapi6 to specify CURRENT behavior is that we don't know how much time will need to wait until it's approved (as I think eapi5 cannot include this extra function as was approved some hours ago). Other option would be to fast release some kind of eapi5.1 adding this... but, again, I think we are discussing about something that could be resolved as simply as specifying current behavior for all existing eapis (as we are in fact doing in the tree) and rely on new eapis for future hypothetical changes on it. The key question is: How would you formally describe the current behavior? I think someone already noted it's not reliable behavior in all places. -- :wq
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
El jue, 20-09-2012 a las 18:55 +0100, Ciaran McCreesh escribió: On Thu, 20 Sep 2012 19:54:43 +0200 Pacho Ramos pa...@gentoo.org wrote: That isn't necessary what could occur if the behavior changes unexpectedly: as current behavior is already being assumed in eclasses/ebuilds, portage couldn't change it without, before, porting ebuilds/eclasses to use that new hypothetical behavior. Sure it can. Portage supports what's in the spec. If you're relying upon undefined behaviour, it's your problem when it stops working. It cannot break the tree, only square-headed people can think somebody would force a breakage and don't try to fix it before. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Thu, 20 Sep 2012 20:02:47 +0200 Pacho Ramos pa...@gentoo.org wrote: We had this discussion when the function was introduced. It's supposed to be used for cosmetic things only. What are cosmetics things? Also, what do you mean by It's supposed? Who should decide what is supposed and what not? The Council decides, by voting on what PMS says. From past discussions I remember somebody remembered me that, when you talk here, you are simply talking as another one subscribed here, like me and others, you don't represent PMS team and have no special rule to forbid us what to do, that is the reason why I asked for more opinions about how to handle this situation in the tree and why I demanded Alexandre to wait a bit before commiting second way because that way simply adds more complication with no benefit apart of address your complaints even leaving the rest of the tree (ebuilds/eclasses already using it) unchanged. You are welcome to read PMS yourself if you like. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Thu, 20 Sep 2012 20:13:00 +0200 Pacho Ramos pa...@gentoo.org wrote: El jue, 20-09-2012 a las 18:55 +0100, Ciaran McCreesh escribió: On Thu, 20 Sep 2012 19:54:43 +0200 Pacho Ramos pa...@gentoo.org wrote: That isn't necessary what could occur if the behavior changes unexpectedly: as current behavior is already being assumed in eclasses/ebuilds, portage couldn't change it without, before, porting ebuilds/eclasses to use that new hypothetical behavior. Sure it can. Portage supports what's in the spec. If you're relying upon undefined behaviour, it's your problem when it stops working. It cannot break the tree, only square-headed people can think somebody would force a breakage and don't try to fix it before. Uhm, if you're relying upon a coincidence of how Portage currently happens to work, you're already broken. -- Ciaran McCreesh 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 20/09/12 02:12 PM, Michael Mol wrote: On Thu, Sep 20, 2012 at 1:58 PM, Pacho Ramos pa...@gentoo.org wrote: El jue, 20-09-2012 a las 10:14 -0400, Ian Stakenvicius escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/09/12 09:52 AM, Ciaran McCreesh wrote: On Thu, 20 Sep 2012 09:13:40 -0400 Ian Stakenvicius a...@gentoo.org wrote: PMS may not need to be fixed, just the spec PMS is the spec, and it doesn't need fixing, since it accurately reflects the situation we're dealing with. Sorry, I misread PMS as PMs (portage, paludis, etc). And, for support to be official for ebuilds or eclasses to query IUSE (or other globals) within phase functions, then the 'spec' (PMS) is probably all that needs to be 'fixed'. Right? So, in EAPI=6, we propose something that'll make it official (ie a querying function; or ensure that PMs can provide these variables along with their proper 'effective' values, or their in-ebuild 'explicit' values, or whatever it is we want to say can be relied upon, to the environment). The problem of waiting for eapi6 to specify CURRENT behavior is that we don't know how much time will need to wait until it's approved (as I think eapi5 cannot include this extra function as was approved some hours ago). Other option would be to fast release some kind of eapi5.1 adding this... but, again, I think we are discussing about something that could be resolved as simply as specifying current behavior for all existing eapis (as we are in fact doing in the tree) and rely on new eapis for future hypothetical changes on it. The key question is: How would you formally describe the current behavior? I think someone already noted it's not reliable behavior in all places. I think we'd need an audit of what current behaviour is and then define based on that. Possibly removing cases where the 'expected' behaviour isn't occurring (ie, bugs that just aren't being caught). I'm biased, so to me just auditing what portage does would be good enough. :D But probably the other PMs should be audited to before 'official' behaviour should be described for PMS. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBbXzcACgkQ2ugaI38ACPBqywEAuXtOrfOy6R+JrwIxfAfcueDe ItsysItZBl+dKdsyShEA/iY8Oye4hyTJc01jT2deBmVPGm3P6Iu/0YZ/tismPAHv =2nvp -END PGP SIGNATURE-
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 20 Sep 2012 14:23:51 -0400 Ian Stakenvicius a...@gentoo.org wrote: I'm biased, so to me just auditing what portage does would be good enough. :D You also need to audit what Portage did since EAPI 0 was introduced. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlBbX30ACgkQ96zL6DUtXhGSAQCg2L9eRwlxxdJF+a+JUkKGCUu8 LagAnjrc7btMreGiERl7FD5UU+iHPWcl =CIJT -END PGP SIGNATURE-
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Thu, Sep 20, 2012 at 2:13 PM, Pacho Ramos pa...@gentoo.org wrote: El jue, 20-09-2012 a las 18:55 +0100, Ciaran McCreesh escribió: On Thu, 20 Sep 2012 19:54:43 +0200 Pacho Ramos pa...@gentoo.org wrote: That isn't necessary what could occur if the behavior changes unexpectedly: as current behavior is already being assumed in eclasses/ebuilds, portage couldn't change it without, before, porting ebuilds/eclasses to use that new hypothetical behavior. Sure it can. Portage supports what's in the spec. If you're relying upon undefined behaviour, it's your problem when it stops working. It cannot break the tree, only square-headed people can think somebody would force a breakage and don't try to fix it before. Isn't this why there are stable and unstable versions of PMs? And why we have things like 'undefined behavior' in language specs? And why depending on them is considered a bad thing? At least in the C world, it's considered within the compiler's rights to take a UB dependency in your code and stick in a routine to play salsa music in an infinite loop while driving your laptop's hard drive to dance across the table. (More frequently, it just omits the code entirely, but that's typically less amusing.) If I'm writing a PM, and I have to make sure my code conforms to some condition, something static like a spec is the only thing I can really depend on. If I use does this break anything in the tree as a test, then I have to re-test every time some someone makes a change to the tree, in case someone stumbled into more undefined behavior that works for the PM they test against, but not for mine. And there's no guarantee somebody else won't commit a different breaking UB-dependent change to the tree in the two hours I spent changing my code to act more like the one they're testing against--assuming they even tested correctly! On the other hand, if there's a spec document, I can say that ebuild is depending on undefined behavior, and then come to an agreement whether the ebuild needs to be changed, or whether the behavior needs to be defined. And if the behavior is defined, then either my PM code or the ebuild code changes to conform. This sounds exactly like a classic de jure vs de facto standards debate...and de facto really only works well when the number of implementations that need to conform with each other is very small--ideally one. -- :wq
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 20/09/12 02:24 PM, Ciaran McCreesh wrote:
On Thu, 20 Sep 2012 14:23:51 -0400 Ian Stakenvicius
a...@gentoo.org wrote:
I'm biased, so to me just auditing what portage does would be
good enough. :D
You also need to audit what Portage did since EAPI 0 was
introduced.
No, I don't think so. What portage does *now* is the important thing
for EAPI={0,1,2,3,4,5}, not what it has done over the course of history.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlBbbQMACgkQ2ugaI38ACPDeFQD8C1//65PwCKUAM6FVHci7AcoU
vuzYaUdCMHD1kEKYea0BAIkJYfkKWsmQCWreNjN+qpwflA1Hrpou/rOFfNpcBGHl
=BJPR
-END PGP SIGNATURE-
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 20 Sep 2012 15:22:43 -0400
Ian Stakenvicius a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 20/09/12 02:24 PM, Ciaran McCreesh wrote:
On Thu, 20 Sep 2012 14:23:51 -0400 Ian Stakenvicius
a...@gentoo.org wrote:
I'm biased, so to me just auditing what portage does would be
good enough. :D
You also need to audit what Portage did since EAPI 0 was
introduced.
No, I don't think so. What portage does *now* is the important thing
for EAPI={0,1,2,3,4,5}, not what it has done over the course of
history.
That would defeat the whole point of having stable EAPIs.
- --
Ciaran McCreesh
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlBbbwMACgkQ96zL6DUtXhHgVACfa/bWAigEnxFiVNU7aJDipgCp
KK0AnAqHNSqKvJDIPglUFvF3WOu64fWj
=nptC
-END PGP SIGNATURE-
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 20/09/12 03:31 PM, Ciaran McCreesh wrote:
On Thu, 20 Sep 2012 15:22:43 -0400 Ian Stakenvicius
a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/09/12 02:24
PM, Ciaran McCreesh wrote:
On Thu, 20 Sep 2012 14:23:51 -0400 Ian Stakenvicius
a...@gentoo.org wrote:
I'm biased, so to me just auditing what portage does would
be good enough. :D
You also need to audit what Portage did since EAPI 0 was
introduced.
No, I don't think so. What portage does *now* is the important
thing for EAPI={0,1,2,3,4,5}, not what it has done over the
course of history.
That would defeat the whole point of having stable EAPIs.
I don't expect we would be modifying older EAPIs , any usage of IUSE
etc within phase functions for those EAPIs would remain undefined imo;
the audit is just to determine what portage (optionally other PMs)
actually do now, to see what can be relied upon so usage of IUSE etc
within phase functions in EAPI6 (or an updated EAPI5, maybe) can be
explicitly stated, without requiring a PM implementation change.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlBbctIACgkQ2ugaI38ACPDKlgD8CYgvFQnuB53qlm8rtbfEK1BL
j3ccHdEFlAHmbloAdSIA/jr7eGR2xhcvl84lEwdLNWMTBr+I5itWBROGV0RTtH33
=1lyp
-END PGP SIGNATURE-
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/09/12 03:31 PM, Ciaran McCreesh wrote: I don't expect we would be modifying older EAPIs , any usage of IUSE etc within phase functions for those EAPIs would remain undefined imo; the audit is just to determine what portage (optionally other PMs) actually do now, to see what can be relied upon so usage of IUSE etc within phase functions in EAPI6 (or an updated EAPI5, maybe) can be explicitly stated, without requiring a PM implementation change. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBbcswACgkQ2ugaI38ACPDIoQD9E9iZsoqketEInGC9RUoJdPsR q286dxqREkQfZHNvQtAA/3V2fm8Uj0w60GfnFCLRqU7Y3dmLoatyBw0fzqhi/s/B =XUdp -END PGP SIGNATURE-
[gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
Pacho Ramos has suggested making vala_src_prepare() into a no-op in the
common situation where vala is in IUSE and USE=-vala.
--- a/vala.eclass
+++ b/vala.eclass
@@ -77,20 +77,36 @@
}
# @FUNCTION: vala_src_prepare
-# @USAGE: [--vala-api-version api_version]
+# @USAGE: [--ignore-use] [--vala-api-version api_version]
# @DESCRIPTION:
# Sets up the environment variables and pkgconfig files for the
# specified API version, or, if no version is specified, for the
# highest installed vala API version satisfying
# VALA_MAX_API_VERSION, VALA_MIN_API_VERSION, and VALA_USE_DEPEND.
-# Dies if called without --vala-api-version and no suitable vala
-# version is found.
+# Is a no-op if called without --ignore-use when USE=-vala.
+# Dies if the USE check is passed (or ignored) and a suitable vala
+# version is not available.
vala_src_prepare() {
- local p d valafoo version
+ local p d valafoo version ignore_use
- if [[ $1 = --vala-api-version ]]; then
- version=$2
- [[ ${version} ]] || die '--vala-api-version' option requires
API version parameter.
+ while [[ $1 ]]; do
+ case $1 in
+ --ignore-use )
+ ignore_use=1 ;;
+ --vala-api-version )
+ shift
+ version=$1
+ [[ ${version} ]] || die '--vala-api-version'
option requires API version parameter.
+ esac
+ shift
+ done
+
+ if [[ -z ${ignore_use} ]]; then
+ has vala ${IUSE//+/} ! use vala return 0
+ fi
+
+ if [[ ${version} ]]; then
+ has_version dev-lang/vala:${version} || die No installed
vala:${version}
else
version=$(vala_best_api_version)
[[ ${version} ]] || die No installed vala in $(vala_depend)
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Wed, 19 Sep 2012 15:26:44 -0400 Alexandre Rostovtsev tetrom...@gentoo.org wrote: Pacho Ramos has suggested making vala_src_prepare() into a no-op in the common situation where vala is in IUSE and USE=-vala. There's no way to obtain the effective value of IUSE from within an ebuild or eclass. You'll need to use an independent variable to get this information. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Wed, 19 Sep 2012 15:26:44 -0400
Alexandre Rostovtsev tetrom...@gentoo.org wrote:
+ if [[ -z ${ignore_use} ]]; then
+ has vala ${IUSE//+/} ! use vala return 0
+ fi
eutils.eclass: in_iuse().
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19/09/12 03:37 PM, Ciaran McCreesh wrote: On Wed, 19 Sep 2012 15:26:44 -0400 Alexandre Rostovtsev tetrom...@gentoo.org wrote: Pacho Ramos has suggested making vala_src_prepare() into a no-op in the common situation where vala is in IUSE and USE=-vala. There's no way to obtain the effective value of IUSE from within an ebuild or eclass. You'll need to use an independent variable to get this information. I don't think that the 'effective' value of IUSE matters in this particular case. This would be the 'explicit' value as is hard-coded in the ebuild that would need to be checked against, I expect? Unless eclasses and phase functions are in the habit of removing entries from IUSE, I don't see this being an issue? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBaLAkACgkQ2ugaI38ACPDeDAD9Ea1CalzAp0poqTh3mTtpwTt8 LVu5vNcZF311lIDJDE0A/jibvhrqIbB5Sw9syPvK8I0j97LGOSXPpZcfN9LYKCHF =1wDn -END PGP SIGNATURE-
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 19 Sep 2012 16:33:13 -0400 Ian Stakenvicius a...@gentoo.org wrote: On 19/09/12 03:37 PM, Ciaran McCreesh wrote: On Wed, 19 Sep 2012 15:26:44 -0400 Alexandre Rostovtsev tetrom...@gentoo.org wrote: Pacho Ramos has suggested making vala_src_prepare() into a no-op in the common situation where vala is in IUSE and USE=-vala. There's no way to obtain the effective value of IUSE from within an ebuild or eclass. You'll need to use an independent variable to get this information. I don't think that the 'effective' value of IUSE matters in this particular case. This would be the 'explicit' value as is hard-coded in the ebuild that would need to be checked against, I expect? Unless eclasses and phase functions are in the habit of removing entries from IUSE, I don't see this being an issue? No, you're not guaranteed to get the ebuild's value of IUSE, or any particular eclass's value of IUSE, or the merged value of IUSE. In particular for this case, it's possible to get false negatives. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlBaLj0ACgkQ96zL6DUtXhHGQACgtfKtKsIt1X3emCWK2qWgrFg5 y5MAn1sK5Pmf2sGFSB7j3bZJDHYr399O =ICAN -END PGP SIGNATURE-
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Wed, 19 Sep 2012 21:42:35 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 19 Sep 2012 16:33:13 -0400 Ian Stakenvicius a...@gentoo.org wrote: On 19/09/12 03:37 PM, Ciaran McCreesh wrote: On Wed, 19 Sep 2012 15:26:44 -0400 Alexandre Rostovtsev tetrom...@gentoo.org wrote: Pacho Ramos has suggested making vala_src_prepare() into a no-op in the common situation where vala is in IUSE and USE=-vala. There's no way to obtain the effective value of IUSE from within an ebuild or eclass. You'll need to use an independent variable to get this information. I don't think that the 'effective' value of IUSE matters in this particular case. This would be the 'explicit' value as is hard-coded in the ebuild that would need to be checked against, I expect? Unless eclasses and phase functions are in the habit of removing entries from IUSE, I don't see this being an issue? No, you're not guaranteed to get the ebuild's value of IUSE, or any particular eclass's value of IUSE, or the merged value of IUSE. In particular for this case, it's possible to get false negatives. Then fix the spec. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Wed, 19 Sep 2012 23:03:05 +0200 Michał Górny mgo...@gentoo.org wrote: No, you're not guaranteed to get the ebuild's value of IUSE, or any particular eclass's value of IUSE, or the merged value of IUSE. In particular for this case, it's possible to get false negatives. Then fix the spec. The spec accurately reflects the mess that is global and metadata variables. Portage has historically done all kinds of different things here (sometimes varying depending upon whether you're a binary, whether things are being loaded from VDB, whether env saving has happened previously etc), and the code is rather sensitive to apparently minor changes in bash versions. Thus we don't provide guarantees. If you want guarantees, propose something for a future EAPI. If you decide to do so, I'd be inclined to suggest proposing a function that gets the actual value of a metadata variable, rather than trying to lock down the value of globals in general. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Wed, 19 Sep 2012 22:14:18 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 19 Sep 2012 23:03:05 +0200 Michał Górny mgo...@gentoo.org wrote: No, you're not guaranteed to get the ebuild's value of IUSE, or any particular eclass's value of IUSE, or the merged value of IUSE. In particular for this case, it's possible to get false negatives. Then fix the spec. The spec accurately reflects the mess that is global and metadata variables. Portage has historically done all kinds of different things here (sometimes varying depending upon whether you're a binary, whether things are being loaded from VDB, whether env saving has happened previously etc), and the code is rather sensitive to apparently minor changes in bash versions. Thus we don't provide guarantees. The historical mess is not relevant anymore. Is there a single real case when IUSE does not contain *at least* the ebuild-set IUSE? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Wed, 19 Sep 2012 23:24:29 +0200 Michał Górny mgo...@gentoo.org wrote: On Wed, 19 Sep 2012 22:14:18 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 19 Sep 2012 23:03:05 +0200 Michał Górny mgo...@gentoo.org wrote: No, you're not guaranteed to get the ebuild's value of IUSE, or any particular eclass's value of IUSE, or the merged value of IUSE. In particular for this case, it's possible to get false negatives. Then fix the spec. The spec accurately reflects the mess that is global and metadata variables. Portage has historically done all kinds of different things here (sometimes varying depending upon whether you're a binary, whether things are being loaded from VDB, whether env saving has happened previously etc), and the code is rather sensitive to apparently minor changes in bash versions. Thus we don't provide guarantees. The historical mess is not relevant anymore. Is there a single real case when IUSE does not contain *at least* the ebuild-set IUSE? The historical mess applies to things under EAPI control. If you want stronger guarantees, you know how to propose things for a future EAPI. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Wed, 19 Sep 2012 22:31:34 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 19 Sep 2012 23:24:29 +0200 Michał Górny mgo...@gentoo.org wrote: On Wed, 19 Sep 2012 22:14:18 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 19 Sep 2012 23:03:05 +0200 Michał Górny mgo...@gentoo.org wrote: No, you're not guaranteed to get the ebuild's value of IUSE, or any particular eclass's value of IUSE, or the merged value of IUSE. In particular for this case, it's possible to get false negatives. Then fix the spec. The spec accurately reflects the mess that is global and metadata variables. Portage has historically done all kinds of different things here (sometimes varying depending upon whether you're a binary, whether things are being loaded from VDB, whether env saving has happened previously etc), and the code is rather sensitive to apparently minor changes in bash versions. Thus we don't provide guarantees. The historical mess is not relevant anymore. Is there a single real case when IUSE does not contain *at least* the ebuild-set IUSE? The historical mess applies to things under EAPI control. If you want stronger guarantees, you know how to propose things for a future EAPI. You didn't answer my question. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Wed, 19 Sep 2012 23:39:43 +0200 Michał Górny mgo...@gentoo.org wrote: The historical mess is not relevant anymore. Is there a single real case when IUSE does not contain *at least* the ebuild-set IUSE? The historical mess applies to things under EAPI control. If you want stronger guarantees, you know how to propose things for a future EAPI. You didn't answer my question. Well no. The point of having a spec for all of this is that we don't have to spend a long time carefully checking things to answer this kind of question every single time a topic is discussed (and this topic has come up quite a few times). You can just look back and see the justification for the spec wording that was given. Then, if you want a change, you can get it in a future EAPI, without us having to worry about working out exactly what the impact will be. Or to put it another way, the point of having a spec is not to give you something to argue about every time it is brought up. The answer to the important question -- is this legal? -- is in the spec. The Council approved the spec. There is a process for changing the spec in a controlled manner. That's all that's relevant to this thread. If you really want to discuss archaeology, you're welcome to start another thread, and see if anyone cares to do the work to give you a detailed answer. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Wed, 19 Sep 2012 22:51:25 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 19 Sep 2012 23:39:43 +0200 Michał Górny mgo...@gentoo.org wrote: The historical mess is not relevant anymore. Is there a single real case when IUSE does not contain *at least* the ebuild-set IUSE? The historical mess applies to things under EAPI control. If you want stronger guarantees, you know how to propose things for a future EAPI. You didn't answer my question. Well no. The point of having a spec for all of this is that we don't have to spend a long time carefully checking things to answer this kind of question every single time a topic is discussed (and this topic has come up quite a few times). You can just look back and see the justification for the spec wording that was given. Then, if you want a change, you can get it in a future EAPI, without us having to worry about working out exactly what the impact will be. Yes, it did. And you are consistently wasting your and ours time complaining that we're doing illegal stuff without trying to bring even a single solution to it. Do you even care? Or are you just complaining because you don't have anything useful to do? If you care, then you should consider finding a good solution which will fix the code now, instead of saying 'it is illegal' and 'we can fix it in an awful way in next 10 years'. Or to put it another way, the point of having a spec is not to give you something to argue about every time it is brought up. You know, good specs come with a thing called 'rationale' for various points. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Thu, 20 Sep 2012 00:13:41 +0200 Michał Górny mgo...@gentoo.org wrote: Yes, it did. And you are consistently wasting your and ours time complaining that we're doing illegal stuff without trying to bring even a single solution to it. Uh, there are plenty of solutions, and they've been discussed every time this topic has come up. Do you even care? Or are you just complaining because you don't have anything useful to do? I care that people write code that actually works. If you care, then you should consider finding a good solution which will fix the code now, instead of saying 'it is illegal' and 'we can fix it in an awful way in next 10 years'. EAPI 5 doesn't appear to be 10 years off. And there are several good solutions, all of which have been discussed previously. The best is to write smaller, less convoluted eclasses that don't mix functionality and overriding default functions. Or to put it another way, the point of having a spec is not to give you something to argue about every time it is brought up. You know, good specs come with a thing called 'rationale' for various points. You're welcome to write it. You seem to have lots of free time. I'd even be happy to point you in the direction of all the previous discussions of this kind of thing, if you have difficulty finding them. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Wed, 19 Sep 2012 23:18:31 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 20 Sep 2012 00:13:41 +0200 If you care, then you should consider finding a good solution which will fix the code now, instead of saying 'it is illegal' and 'we can fix it in an awful way in next 10 years'. EAPI 5 doesn't appear to be 10 years off. And there are several good solutions, all of which have been discussed previously. The best is to write smaller, less convoluted eclasses that don't mix functionality and overriding default functions. And what can I do about it? People want it this way. Or to put it another way, the point of having a spec is not to give you something to argue about every time it is brought up. You know, good specs come with a thing called 'rationale' for various points. You're welcome to write it. You seem to have lots of free time. I'd even be happy to point you in the direction of all the previous discussions of this kind of thing, if you have difficulty finding them. Rationale should be written by the person writing the spec, don't you know? It's your words, so your rationale. Your duty. I can give my rationale for my ideas. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
On Thu, 20 Sep 2012 00:30:25 +0200 Michał Górny mgo...@gentoo.org wrote: On Wed, 19 Sep 2012 23:18:31 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 20 Sep 2012 00:13:41 +0200 If you care, then you should consider finding a good solution which will fix the code now, instead of saying 'it is illegal' and 'we can fix it in an awful way in next 10 years'. EAPI 5 doesn't appear to be 10 years off. And there are several good solutions, all of which have been discussed previously. The best is to write smaller, less convoluted eclasses that don't mix functionality and overriding default functions. And what can I do about it? People want it this way. You can help people write smaller, less convoluted eclasses that don't mix functionality and overriding default functions. Rationale should be written by the person writing the spec, don't you know? It's your words, so your rationale. Your duty. The general impression I get is that most people would rather we spent time on functionality and accuracy rather than history. Most people are content with the Council says so as the rationale, and are happy to restrict their queries to polite requests for historical discussion on interesting topics every now and again (and those that aren't also seem intent upon disagreeing with everything else in the spec anyway). You are of course welcome to propose to the Council that they require detailed historical background for every part of the spec, and then do your duty in writing it up if they agree. -- Ciaran McCreesh signature.asc Description: PGP signature
