1 |
El dom, 23-09-2012 a las 09:36 +0200, Pacho Ramos escribió: |
2 |
> El dom, 23-09-2012 a las 05:52 +0000, Alec Warner escribió: |
3 |
> > On Sat, Sep 22, 2012 at 7:22 PM, Pacho Ramos <pacho@g.o> wrote: |
4 |
> > > El sáb, 22-09-2012 a las 13:54 -0400, Mike Frysinger escribió: |
5 |
> > >> On Friday 21 September 2012 15:08:20 Pacho Ramos wrote: |
6 |
> > >> > In that one, we try to use the following: |
7 |
> > >> > has vala ${IUSE//+/} && ! use vala && return 0 |
8 |
> > >> |
9 |
> > >> inherit eutils |
10 |
> > >> use_if_iuse vala |
11 |
> > >> -mike |
12 |
> > > |
13 |
> > > I am aware of that one also, but Ciaran also wants to forbid it for the |
14 |
> > > same reason :S |
15 |
> > |
16 |
> > Well I assume Ciaran wants to forbid it because he is attempting to |
17 |
> > write a PMS compliant PM; but in order to use these ebuilds properly |
18 |
> > he has to emulate the unspecified behavior that the ebuilds rely on |
19 |
> > upon. His claim is that the council is supposed to forbid this |
20 |
> > behavior (presumably to make his job less horrible) but I don't see |
21 |
> > them beating down your door to change it (and the behavior is not |
22 |
> > new.) |
23 |
> > |
24 |
> > -A |
25 |
> > |
26 |
> > |
27 |
> |
28 |
> My point of view is that, as this is already supported in portage (and |
29 |
> probably in other PMs as, otherwise, they would have had a lot of |
30 |
> problems with, for example, a lot of packages inheritting important |
31 |
> eclasses like gnome2, cmake-utils or xorg-2) and also used in the tree |
32 |
> for years, the easiest solution is to simply specify current behavior |
33 |
> for existing eapis, needing to wait for a new one to change that |
34 |
> behavior. |
35 |
> |
36 |
> As I pointed in http://www.gossamer-threads.com/lists/gentoo/dev/260662 |
37 |
> other options would be: |
38 |
> - wait for next eapi to specify that, the problem is that, if that eapi |
39 |
> take a long time to be approved, we would need to move all |
40 |
> eclasses/ebuilds to the other non-automatic way to later revert |
41 |
> them back. |
42 |
> - include this specification in eapi5 as it's still not allowed in the |
43 |
> tree (maybe for this a council meeting should be soon enough I guess) |
44 |
> |
45 |
|
46 |
As looks like this topic got stalled :(, not sure how hard would be to |
47 |
implement (and document for PMS) the IUSE_FLATTENED idea over current |
48 |
portage implementation: |
49 |
http://www.gossamer-threads.com/lists/gentoo/dev/260812#260812 |