| 1 |
El mar, 25-09-2012 a las 11:24 +0200, Fabian Groffen escribió: |
| 2 |
> In two weeks from now, the council will meet again. This is the time to |
| 3 |
> raise and prepare items that the council should put on the agenda to |
| 4 |
> discuss or vote on. |
| 5 |
> |
| 6 |
> Please respond to this email with agenda items. Please do not hestitate |
| 7 |
> to repeat your agenda item here with a pointer if you previously |
| 8 |
> suggested one (since the last meeting). |
| 9 |
> |
| 10 |
> The agenda for the next meeting will be sent out on Tuesday 2th of |
| 11 |
> October 2012. |
| 12 |
> |
| 13 |
> Please respond to the gentoo-project list, if possible. |
| 14 |
> |
| 15 |
> Fabian |
| 16 |
> |
| 17 |
> |
| 18 |
|
| 19 |
This is from: |
| 20 |
http://www.gossamer-threads.com/lists/gentoo/dev/260662 |
| 21 |
|
| 22 |
But corrected to remember preferred usage of in_iuse from eutils.eclass |
| 23 |
as remembered by mgorny in that thread: |
| 24 |
|
| 25 |
--------- Mensaje reenviado -------- |
| 26 |
De: Pacho Ramos <pacho@g.o> |
| 27 |
Reply-to: gentoo-dev@l.g.o |
| 28 |
Para: gentoo-dev@l.g.o |
| 29 |
Asunto: [gentoo-dev] Suggest to specify a way to query for USEs in next |
| 30 |
council |
| 31 |
Fecha: Sat, 22 Sep 2012 21:41:24 +0200 |
| 32 |
|
| 33 |
Hello |
| 34 |
|
| 35 |
This comes from: |
| 36 |
http://www.gossamer-threads.com/lists/gentoo/dev/260536 |
| 37 |
|
| 38 |
In that one, we try to use the following: |
| 39 |
has vala ${IUSE//+/} && ! use vala && return 0 |
| 40 |
|
| 41 |
as already done in many eclasses/ebuilds (some of them as widely used as |
| 42 |
xorg-2 or cmake eclasses) for years. The problem is that Ciaran |
| 43 |
wants to forbid it because he says it's not specified in PMS and also |
| 44 |
the same looks to apply to preferred in_iuse function from eutils.eclass |
| 45 |
|
| 46 |
My suggestion is to simply specify it as it's currently implemented in |
| 47 |
portage because that functionality is (apart of needed) being used for a |
| 48 |
long time in the tree by numerous eclasses/ebuilds, then, from my point |
| 49 |
of view, wouldn't be any sense on lose time for moving them to current |
| 50 |
functionality to a worse one, wait for the next eapi and, finally, |
| 51 |
revert them back to current behavior. The way it works was kindly |
| 52 |
explained to me yesterday by Zac: |
| 53 |
http://www.mail-archive.com/gentoo-portage-dev@l.g.o/msg02830.html |
| 54 |
|
| 55 |
If the behavior need to be changed later in a way it would break the |
| 56 |
tree, we could, then, wait for next eapi to change that behavior. |
| 57 |
|
| 58 |
Other option would be to wait for next eapi to specify that, the problem |
| 59 |
is that, if that eapi take a long time to be approved, we would need to |
| 60 |
move all eclasses/ebuilds to the other non-automatic way to later revert |
| 61 |
them back. |
| 62 |
|
| 63 |
And other option could be to include this specification in eapi5 as it's |
| 64 |
still not allowed in the tree (maybe for this a council meeting should |
| 65 |
be soon enough I guess) |
| 66 |
|
| 67 |
Thanks a lot |
Archives