Gentoo Archives: gentoo-portage-dev

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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies