[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@g.o>
>> 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