FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 09-20-2012, 01:13 PM
Ian Stakenvicius
 
Default 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 <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)

iF4EAREIAAYFAlBbFoQACgkQ2ugaI38ACPCWIAEAkDBX6zRm9u AygFTAoNuVKPEq
Weq2eFQATLdYjUQ1HhoA/0dG89SayOG3gjSefG92A62H+EeBARQpPpa/xxAqoESi
=hhU4
-----END PGP SIGNATURE-----
 
Old 09-20-2012, 01:52 PM
Ciaran McCreesh
 
Default 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 <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)

iEYEARECAAYFAlBbH48ACgkQ96zL6DUtXhEfFACfebA7J5jLGh xs3wJoW62juu1j
4GEAoMgcNjRGVxN7Dvfph6lnETsuXUIR
=Uud8
-----END PGP SIGNATURE-----
 
Old 09-20-2012, 02:14 PM
Ian Stakenvicius
 
Default 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
> <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+L R7mir9my5Z7t/9
/3VzJvgozs47ybh3ZrUA/R6rca5Ts/lEn2FWVOpqcK9ajyD8pa9wHaKTzEXpq2+v
=F0jI
-----END PGP SIGNATURE-----
 
Old 09-20-2012, 02:26 PM
Ciaran McCreesh
 
Default 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 <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)

iEYEARECAAYFAlBbJ5IACgkQ96zL6DUtXhFA7wCcDnPCizqcqF ImdkjSqcG599wU
PygAn2W/8qX9tjgQUYM1KXhcUeCnpCcK
=7kyg
-----END PGP SIGNATURE-----
 
Old 09-20-2012, 02:40 PM
Ian Stakenvicius
 
Default 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
> <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-----
 
Old 09-20-2012, 05:52 PM
Pacho Ramos
 
Default 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.
 
Old 09-20-2012, 05:54 PM
Pacho Ramos
 
Default 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 <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.
 
Old 09-20-2012, 05:55 PM
Ciaran McCreesh
 
Default vala.eclass: change vala_src_prepare behavior when USE=-vala

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
 
Old 09-20-2012, 05:55 PM
Ciaran McCreesh
 
Default vala.eclass: change vala_src_prepare behavior when USE=-vala

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
 
Old 09-20-2012, 05:56 PM
Pacho Ramos
 
Default 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 <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.
 

Thread Tools




All times are GMT. The time now is 09:53 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org