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

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
 
Old 09-20-2012, 06:12 PM
Michael Mol
 
Default vala.eclass: change vala_src_prepare behavior when USE=-vala

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
 
Old 09-20-2012, 06:13 PM
Pacho Ramos
 
Default 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 <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.
 
Old 09-20-2012, 06:15 PM
Ciaran McCreesh
 
Default vala.eclass: change vala_src_prepare behavior when USE=-vala

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
 
Old 09-20-2012, 06:23 PM
Ian Stakenvicius
 
Default 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 <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. 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-----
 
Old 09-20-2012, 06:24 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 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.

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)

iEYEARECAAYFAlBbX30ACgkQ96zL6DUtXhGSAQCg2L9eRwlxxd JF+a+JUkKGCUu8
LagAnjrc7btMreGiERl7FD5UU+iHPWcl
=CIJT
-----END PGP SIGNATURE-----
 
Old 09-20-2012, 06:33 PM
Michael Mol
 
Default vala.eclass: change vala_src_prepare behavior when USE=-vala

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
 
Old 09-20-2012, 07:22 PM
Ian Stakenvicius
 
Default 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
> <axs@gentoo.org> wrote:
>> I'm biased, so to me just auditing what portage does would be
>> good enough.
>
> 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+qpwflA1Hrp ou/rOFfNpcBGHl
=BJPR
-----END PGP SIGNATURE-----
 

Thread Tools




All times are GMT. The time now is 07:52 AM.

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