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 |
> |