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, 07:31 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 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.
> >
> > 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-----
 
Old 09-20-2012, 07:47 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: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.
>>>
>>> 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)

iF4EAREIAAYFAlBbctIACgkQ2ugaI38ACPDKlgD8CYgvFQnuB5 3qlm8rtbfEK1BL
j3ccHdEFlAHmbloAdSIA/jr7eGR2xhcvl84lEwdLNWMTBr+I5itWBROGV0RTtH33
=1lyp
-----END PGP SIGNATURE-----
 
Old 09-20-2012, 07:47 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: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)

iF4EAREIAAYFAlBbcswACgkQ2ugaI38ACPDIoQD9E9iZsoqket EInGC9RUoJdPsR
q286dxqREkQfZHNvQtAA/3V2fm8Uj0w60GfnFCLRqU7Y3dmLoatyBw0fzqhi/s/B
=XUdp
-----END PGP SIGNATURE-----
 
Old 09-20-2012, 10:42 PM
Duncan
 
Default vala.eclass: change vala_src_prepare behavior when USE=-vala

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
 
Old 09-21-2012, 07:01 PM
Pacho Ramos
 
Default vala.eclass: change vala_src_prepare behavior when USE=-vala

El jue, 20-09-2012 a las 14:23 -0400, Ian Stakenvicius escribió:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 20/09/12 02:12 PM, Michael Mol wrote:
> > On Thu, Sep 20, 2012 at 1:58 PM, Pacho Ramos <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.
>

Will ask to portage people then to know what is current behavior
 
Old 09-22-2012, 08:07 AM
Pacho Ramos
 
Default vala.eclass: change vala_src_prepare behavior when USE=-vala

El vie, 21-09-2012 a las 21:01 +0200, Pacho Ramos escribió:
> El jue, 20-09-2012 a las 14:23 -0400, Ian Stakenvicius escribió:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > On 20/09/12 02:12 PM, Michael Mol wrote:
> > > On Thu, Sep 20, 2012 at 1:58 PM, Pacho Ramos <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.
> >
>
> 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
 

Thread Tools




All times are GMT. The time now is 07:11 PM.

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