Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012

[Pacho Ramos <pacho@gentoo.org>]

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

El mar, 25-09-2012 a las 11:24 +0200, Fabian Groffen escribió:
> In two weeks from now, the council will meet again. This is the time to
> raise and prepare items that the council should put on the agenda to
> discuss or vote on.
> 
> Please respond to this email with agenda items. Please do not hestitate
> to repeat your agenda item here with a pointer if you previously
> suggested one (since the last meeting).
> 
> The agenda for the next meeting will be sent out on Tuesday 2th of
> October 2012.
> 
> Please respond to the gentoo-project list, if possible.
> 
> Fabian
> 
> 

This is from:
http://www.gossamer-threads.com/lists/gentoo/dev/260662

But corrected to remember preferred usage of in_iuse from eutils.eclass
as remembered by mgorny in that thread:

--------- Mensaje reenviado --------
De: Pacho Ramos <pacho@gentoo.org>
Reply-to: gentoo-dev@lists.gentoo.org
Para: gentoo-dev@lists.gentoo.org
Asunto: [gentoo-dev] Suggest to specify a way to query for USEs in next
council
Fecha: Sat, 22 Sep 2012 21:41:24 +0200

Hello

This comes from:
http://www.gossamer-threads.com/lists/gentoo/dev/260536

In that one, we try to use the following:
has vala ${IUSE//+/} && ! use vala && return 0 

as already done in many eclasses/ebuilds (some of them as widely used as
xorg-2 or cmake eclasses) for years. The problem is that Ciaran
wants to forbid it because he says it's not specified in PMS and also
the same looks to apply to preferred in_iuse function from eutils.eclass

My suggestion is to simply specify it as it's currently implemented in
portage because that functionality is (apart of needed) being used for a
long time in the tree by numerous eclasses/ebuilds, then, from my point
of view, wouldn't be any sense on lose time for moving them to current
functionality to a worse one, wait for the next eapi and, finally,
revert them back to current behavior. The way it works was kindly
explained to me yesterday by Zac:
http://www.mail-archive.com/gentoo-portage-dev@lists.gentoo.org/msg02830.html

If the behavior need to be changed later in a way it would break the
tree, we could, then, wait for next eapi to change that behavior.

Other option would be to wait for next eapi to specify that, the problem
is that, if that eapi take a long time to be approved, we would need to
move all eclasses/ebuilds to the other non-automatic way to later revert
them back.

And other option could be to include this specification in eapi5 as it's
still not allowed in the tree (maybe for this a council meeting should
be soon enough I guess)

Thanks a lot


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