On Wednesday, 30 October 2013, Ruud Koolen wrote:
> On Tuesday 29 October 2013 08:40:59 Michael Haubenwallner wrote:
> > On 10/26/13 00:54, Ruud Koolen wrote:
> > > It's bikeshedding time.
> > >
> > > The RAP project (prefix with libc) is now ready to start getting merged
> > >
> > > I propose "prefix-native" for rap as an alternative. Does anyone have
> any
> > > good ideas for classic prefix?
> >
> > As you say "prefix with libc" above: Is it necessary to /split/ Prefix
> into
> > $rap and $classic, or would it also fit to have $rap to /supplement/
> > classic?
>
> In what sense? On the profile level, we factor out the common base shared
> between classic and rap (which is about 50%-75% of the existing profile),
> and
> have both variants inherit this base (neither can inherit the other
> directly). As for USE flags, the primary function of the new use flags is
> to
> disable certain hacks in rap. Writing those as `if use prefix && ! use
> prefix-libc` is not a nice situation, so we need both new flags.
Admittedly, I haven't followed this whole discussion, but if you add
another "implicit" USE flag (like USE=prefix), you will have a heated
battle with the community of developers and other package managers. I
started the battle years ago, so I do know abit but things may have changed
:)
-Jeremy
>
> We keep USE=prefix, of course. The vast majority of cases of prefix
> support in
> ebuilds applies equally to classic and rap; those will keep using `if use
> prefix`. The new flags are solely for the handful of ebuilds that need to
> distinguish between the variants.
>
> > In case of the latter, I could think of:
> >
> > profiles/base/make.defaults:
> > USE_EXPAND_UNPREFIXED+=" PREFIX" # for backwards compat, or we get
> > "prefix_prefix" USE_EXPAND_HIDDEN+=" PREFIX"
> > USE_EXPAND_IMPLICIT+=" PREFIX"
> > USE_EXPAND_VALUES_PREFIX="prefix prefix-libc"
> > And to help bug#473598 eventually:
> > USE_EXPAND_VALUES_PREFIX+=" ${USE_EXPAND_VALUES_ARCH//*-*}" # the
> > base-archs only
>
> I don't think I understand this.
>
> > To distinguish between glibc/uclibc/etc, existing ELIBC could do.
>
> Yeah, that's fine.
>
> > For the profiles itself:
> > profiles/default/linux/$arch/13.0/prefix and
> > profiles/default/linux/$arch/13.0/prefix/glibc
> > profiles/default/linux/$arch/13.0/prefix/uclibc
> > or even
> > profiles/default/linux/$arch/13.0/prefix and
> > profiles/default/linux/$arch/13.0/prefix/libc/glibc
> > profiles/default/linux/$arch/13.0/prefix/libc/uclibc
>
> Which variant will be considered the default and thus get the glorious
> profiles/default/linux/$arch/13.0/prefix name is a mostly unrelated matter.
>
> -- Ruud
>
>
