[gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Alexandre Rostovtsev]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

On Wed, 19 Sep 2012 15:26:44 -0400
Alexandre Rostovtsev <tetromino@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Ian Stakenvicius]

-----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
> <tetromino@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

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 19 Sep 2012 16:33:13 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:
> On 19/09/12 03:37 PM, Ciaran McCreesh wrote:
> > On Wed, 19 Sep 2012 15:26:44 -0400 Alexandre Rostovtsev
> > <tetromino@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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]

On Wed, 19 Sep 2012 21:42:35 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wed, 19 Sep 2012 16:33:13 -0400
> Ian Stakenvicius <axs@gentoo.org> wrote:
> > On 19/09/12 03:37 PM, Ciaran McCreesh wrote:
> > > On Wed, 19 Sep 2012 15:26:44 -0400 Alexandre Rostovtsev
> > > <tetromino@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

On Wed, 19 Sep 2012 23:03:05 +0200
Michał Górny <mgorny@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

On Wed, 19 Sep 2012 22:14:18 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Wed, 19 Sep 2012 23:03:05 +0200
> Michał Górny <mgorny@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

On Wed, 19 Sep 2012 23:24:29 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Wed, 19 Sep 2012 22:14:18 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Wed, 19 Sep 2012 23:03:05 +0200
> > Michał Górny <mgorny@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

On Wed, 19 Sep 2012 22:31:34 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Wed, 19 Sep 2012 23:24:29 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > On Wed, 19 Sep 2012 22:14:18 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > On Wed, 19 Sep 2012 23:03:05 +0200
> > > Michał Górny <mgorny@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1436 bytes --]

On Wed, 19 Sep 2012 23:39:43 +0200
Michał Górny <mgorny@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]

On Wed, 19 Sep 2012 22:51:25 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Wed, 19 Sep 2012 23:39:43 +0200
> Michał Górny <mgorny@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]

On Thu, 20 Sep 2012 00:13:41 +0200
Michał Górny <mgorny@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

On Wed, 19 Sep 2012 23:18:31 +0100
Ciaran McCreesh <ciaran.mccreesh@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]

On Thu, 20 Sep 2012 00:30:25 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Wed, 19 Sep 2012 23:18:31 +0100
> Ciaran McCreesh <ciaran.mccreesh@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

On Wed, 19 Sep 2012 15:26:44 -0400
Alexandre Rostovtsev <tetromino@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Alexandre Rostovtsev]

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

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

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.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Alexandre Rostovtsev]

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.

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.

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 3044 bytes --]

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.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 216 bytes --]

On Thu, 20 Sep 2012 19:52:11 +0200
Pacho Ramos <pacho@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]

On Thu, 20 Sep 2012 08:43:11 +0200
Pacho Ramos <pacho@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Ian Stakenvicius]

-----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 <pacho@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

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 20 Sep 2012 09:13:40 -0400
Ian Stakenvicius <axs@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

[Ian Stakenvicius]

-----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
> <axs@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

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 20 Sep 2012 10:14:32 -0400
Ian Stakenvicius <axs@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

[Ian Stakenvicius]

-----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
> <axs@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

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]

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
> > <axs@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.




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Michael Mol]

On Thu, Sep 20, 2012 at 1:58 PM, Pacho Ramos <pacho@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
>> > <axs@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

[Ian Stakenvicius]

-----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 <pacho@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 
>>>> <axs@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

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 20 Sep 2012 14:23:51 -0400
Ian Stakenvicius <axs@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

[Ian Stakenvicius]

-----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
> <axs@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

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 20 Sep 2012 15:22:43 -0400
Ian Stakenvicius <axs@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
> > <axs@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

[Ian Stakenvicius]

-----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-----

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Ian Stakenvicius]

-----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 
> <axs@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 
>>> <axs@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

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 2613 bytes --]

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 <pacho@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 
> >>>> <axs@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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 2888 bytes --]

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 <pacho@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 
> > >>>> <axs@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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 854 bytes --]

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 <axs@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.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 2662 bytes --]

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 <pacho@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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

On Thu, 20 Sep 2012 19:54:43 +0200
Pacho Ramos <pacho@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 694 bytes --]

El jue, 20-09-2012 a las 18:55 +0100, Ciaran McCreesh escribió:
> On Thu, 20 Sep 2012 19:54:43 +0200
> Pacho Ramos <pacho@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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 926 bytes --]

On Thu, 20 Sep 2012 20:13:00 +0200
Pacho Ramos <pacho@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 <pacho@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Michael Mol]

On Thu, Sep 20, 2012 at 2:13 PM, Pacho Ramos <pacho@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 <pacho@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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 777 bytes --]

On Thu, 20 Sep 2012 08:43:11 +0200
Pacho Ramos <pacho@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]

El jue, 20-09-2012 a las 09:10 +0100, Ciaran McCreesh escribió:
> On Thu, 20 Sep 2012 08:43:11 +0200
> Pacho Ramos <pacho@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.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

On Thu, 20 Sep 2012 20:02:47 +0200
Pacho Ramos <pacho@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: vala.eclass: change vala_src_prepare behavior when USE=-vala

[Duncan]

Pacho Ramos posted on Thu, 20 Sep 2012 20:02:47 +0200 as excerpted:

> El jue, 20-09-2012 a las 09:10 +0100, Ciaran McCreesh escribió:
>> On Thu, 20 Sep 2012 08:43:11 +0200 Pacho Ramos <pacho@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?

I had forgotten that until Ciaran jogged my memory, but I believe I 
remember the discussion about it now.

"Cosmetic" in this case means things like post-install reminder messages, 
etc.  Things that don't affect actual ebuild functionality to the point 
of breaking packages, but only affect things like elog messages.

And in context, "supposed" would be that while the eclass function was 
added over the objection of it conflicting with PMS, the objections were 
dropped (as opposed to taking it to devrel and/or thru to council... 
which after all approves PMS wording) when the people in favor of the 
function agreed to only use it for non-critical (that is, cosmetic, as 
described above, generally messages only) functionality.  Using it for 
anything that actually changes what's installed would be a violation of 
that agreement, and thus, could result in complaints, which could be 
taken thru qa, devrel and ultimately up to council, if the disagreement 
couldn't be worked out some other way, before it got to that level.

That's from memory, but I expect if someone bothers to go dig around in 
the archives, it'll be found to be reasonably accurate.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman