Gentoo Archives: gentoo-alt

From: Jeremy Olexa <darkside@g.o>
To: "gentoo-alt@l.g.o" <gentoo-alt@l.g.o>
Subject: Re: [gentoo-alt] Names of Prefix variants
Date: Thu, 31 Oct 2013 05:03:40
Message-Id: CAMxqorX+Uy64JbburXwCs_gu696q=xaTAaoFJA-hGSTA=QiVMA@mail.gmail.com
In Reply to: Re: [gentoo-alt] Names of Prefix variants by Ruud Koolen
1 On Wednesday, 30 October 2013, Ruud Koolen wrote:
2
3 > On Tuesday 29 October 2013 08:40:59 Michael Haubenwallner wrote:
4 > > On 10/26/13 00:54, Ruud Koolen wrote:
5 > > > It's bikeshedding time.
6 > > >
7 > > > The RAP project (prefix with libc) is now ready to start getting merged
8 > > >
9 > > > I propose "prefix-native" for rap as an alternative. Does anyone have
10 > any
11 > > > good ideas for classic prefix?
12 > >
13 > > As you say "prefix with libc" above: Is it necessary to /split/ Prefix
14 > into
15 > > $rap and $classic, or would it also fit to have $rap to /supplement/
16 > > classic?
17 >
18 > In what sense? On the profile level, we factor out the common base shared
19 > between classic and rap (which is about 50%-75% of the existing profile),
20 > and
21 > have both variants inherit this base (neither can inherit the other
22 > directly). As for USE flags, the primary function of the new use flags is
23 > to
24 > disable certain hacks in rap. Writing those as `if use prefix && ! use
25 > prefix-libc` is not a nice situation, so we need both new flags.
26
27
28 Admittedly, I haven't followed this whole discussion, but if you add
29 another "implicit" USE flag (like USE=prefix), you will have a heated
30 battle with the community of developers and other package managers. I
31 started the battle years ago, so I do know abit but things may have changed
32 :)
33
34 -Jeremy
35
36
37 >
38 > We keep USE=prefix, of course. The vast majority of cases of prefix
39 > support in
40 > ebuilds applies equally to classic and rap; those will keep using `if use
41 > prefix`. The new flags are solely for the handful of ebuilds that need to
42 > distinguish between the variants.
43 >
44 > > In case of the latter, I could think of:
45 > >
46 > > profiles/base/make.defaults:
47 > > USE_EXPAND_UNPREFIXED+=" PREFIX" # for backwards compat, or we get
48 > > "prefix_prefix" USE_EXPAND_HIDDEN+=" PREFIX"
49 > > USE_EXPAND_IMPLICIT+=" PREFIX"
50 > > USE_EXPAND_VALUES_PREFIX="prefix prefix-libc"
51 > > And to help bug#473598 eventually:
52 > > USE_EXPAND_VALUES_PREFIX+=" ${USE_EXPAND_VALUES_ARCH//*-*}" # the
53 > > base-archs only
54 >
55 > I don't think I understand this.
56 >
57 > > To distinguish between glibc/uclibc/etc, existing ELIBC could do.
58 >
59 > Yeah, that's fine.
60 >
61 > > For the profiles itself:
62 > > profiles/default/linux/$arch/13.0/prefix and
63 > > profiles/default/linux/$arch/13.0/prefix/glibc
64 > > profiles/default/linux/$arch/13.0/prefix/uclibc
65 > > or even
66 > > profiles/default/linux/$arch/13.0/prefix and
67 > > profiles/default/linux/$arch/13.0/prefix/libc/glibc
68 > > profiles/default/linux/$arch/13.0/prefix/libc/uclibc
69 >
70 > Which variant will be considered the default and thus get the glorious
71 > profiles/default/linux/$arch/13.0/prefix name is a mostly unrelated matter.
72 >
73 > -- Ruud
74 >
75 >