| 1 |
Hello |
| 2 |
|
| 3 |
This comes from: |
| 4 |
http://www.gossamer-threads.com/lists/gentoo/dev/260536 |
| 5 |
|
| 6 |
In that one, we try to use the following: |
| 7 |
has vala ${IUSE//+/} && ! use vala && return 0 |
| 8 |
|
| 9 |
as already done in many eclasses/ebuilds (some of them as widely used as |
| 10 |
xorg-2 or cmake eclasses) for years. The problem is that Ciaran |
| 11 |
wants to forbid it because he says it's not specified in PMS. |
| 12 |
|
| 13 |
My suggestion is to simply specify it as it's currently implemented in |
| 14 |
portage because that functionality is (apart of needed) being used for a |
| 15 |
long time in the tree by numerous eclasses/ebuilds, then, from my point |
| 16 |
of view, wouldn't be any sense on lose time for moving them to current |
| 17 |
functionality to a worse one, wait for the next eapi and, finally, |
| 18 |
revert them back to current behavior. The way it works was kindly |
| 19 |
explained to me yesterday by Zac: |
| 20 |
http://www.mail-archive.com/gentoo-portage-dev@l.g.o/msg02830.html |
| 21 |
|
| 22 |
If the behavior need to be changed later in a way it would break the |
| 23 |
tree, we could, then, wait for next eapi to change that behavior. |
| 24 |
|
| 25 |
Other option would be to wait for next eapi to specify that, the problem |
| 26 |
is that, if that eapi take a long time to be approved, we would need to |
| 27 |
move all eclasses/ebuilds to the other non-automatic way to later revert |
| 28 |
them back. |
| 29 |
|
| 30 |
And other option could be to include this specification in eapi5 as it's |
| 31 |
still not allowed in the tree (maybe for this a council meeting should |
| 32 |
be soon enough I guess) |
| 33 |
|
| 34 |
Thanks a lot |
Archives