[gentoo-alt] Names of Prefix variants

[gentoo-alt] Names of Prefix variants

[Ruud Koolen]

It's bikeshedding time.

The RAP project (prefix with libc) is now ready to start getting merged into 
gx86 and (if necessary) prefix overlay, thus giving it some form of official 
status. Part of that job is writing new profiles for RAP, and adding USE 
flags allowing ebuilds to distinguish between the two variants of prefix: 
classic, and RAP. For both purposes, we need names for the two variants, and 
preferably clear and descriptive names too.

For the profiles, the plan is to add profiles 
default/linux/$arch/13.0/prefix/$classic and 
default/linux/$arch/13.0/prefix/$rap, possibly with one of the two variants 
being default and thus renamed to default/linux/$arch/13.0/prefix; 
default/linux/$arch/13.0/prefix/$classic would symlink to prefix/linux/$arch, 
or vice versa, and default/linux/$arch/13.0/prefix/$rap would be the all-new 
RAP profile. (They will probably have a considerable amount of shared 
structure factored out, but that's another matter.)

For the USE flags, there are a handful of ebuilds that need to distinguish 
between prefix classic and prefix RAP: the toolchains work differently, and 
the fact that RAP doesn't have /usr/include, /lib, and /usr/lib as valid 
search paths causes complications for some packages. To support this, the 
plan is to introduce two new global USE flags, prefix-$classic and 
prefix-$rap, both of which are masked in the base profile and selectively 
unmasked in the different prefix profiles.

For both purposes, we need names for the two variants. The names should have 
the property that their meaning should be reasonably clear to the 
uninitiated, not too ugly, and somewhat accurately describe the difference 
between the two versions. Specifically, reading the two profile names should 
give you a good indication of which one to choose, and seeing `if use 
prefix-$classic` in an ebuild should give the reader a fairly good idea of 
what's going on.

During development, we've been using the name "prefix-rpath" for classic, 
and "prefix-libc" and "rap" for rap. Of those, I think prefix-rpath is 
acceptable, but could be improved; the other two are just bad, as far as I'm 
concerned, and should be replaced.

I propose "prefix-native" for rap as an alternative. Does anyone have any good 
ideas for classic prefix?

-- Ruud

Re: [gentoo-alt] Names of Prefix variants

[Greg Turner]

On Fri, Oct 25, 2013 at 3:54 PM, Ruud Koolen <redlizard@gentoo.org> wrote:
> RAP doesn't have /usr/include, /lib, and /usr/lib as valid
> search paths

I didn't know that.  I think it's wonderful!  Eager to see if this
fixes the fail-fest that arises attempting to run prefixes on multilib
platforms where ARCH of the prefix does not correspond to the default
abi of the host!

Re: [gentoo-alt] Names of Prefix variants

[Ruud Koolen]

On Saturday 26 October 2013 02:23:18 Greg Turner wrote:
> I didn't know that.  I think it's wonderful!  Eager to see if this
> fixes the fail-fest that arises attempting to run prefixes on multilib
> platforms where ARCH of the prefix does not correspond to the default
> abi of the host!

It should.

Re: [gentoo-alt] Names of Prefix variants

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]

On 26-10-2013 00:54:48 +0200, Ruud Koolen wrote:
> During development, we've been using the name "prefix-rpath" for classic, 
> and "prefix-libc" and "rap" for rap. Of those, I think prefix-rpath is 
> acceptable, but could be improved; the other two are just bad, as far as I'm 
> concerned, and should be replaced.
> 
> I propose "prefix-native" for rap as an alternative. Does anyone have any good 
> ideas for classic prefix?

As you may or may not know, the prefix USE-flag is a hack that works in
Portage, but violates specifications, because it is never defined in
ebuilds that need it.  Discussions here go back to not wanting to show
elibc_XXX, kernel_XXX in IUSE (because user can't influence them) and
prefix likewise.  We should still solve this problem.  While we're at
it, I'd like to tackle bug #473598 [1] at the same time.

Anyway, I was thinking more along the lines of using USE_EXPAND.
There's also a USE_EXPAND_HIDDEN, and something like this [2] looks
good.  In other words, I could think of having EPREFIX="$classic" or
EPREFIX_TARGET="$rap", which could default to $classic in
base/make.defaults.

Thoughts?

Fabian


[1] https://bugs.gentoo.org/show_bug.cgi?id=473598
[2] embedded/make.defaults:USE_EXPAND_HIDDEN="USERLAND KERNEL ELIBC CROSSCOMPILE_OPTS ABI_MIPS ABI_X86"


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-alt] Names of Prefix variants

[Ruud Koolen]

On Saturday 26 October 2013 09:41:28 Fabian Groffen wrote:
> As you may or may not know, the prefix USE-flag is a hack that works in
> Portage, but violates specifications, because it is never defined in
> ebuilds that need it.  Discussions here go back to not wanting to show
> elibc_XXX, kernel_XXX in IUSE (because user can't influence them) and
> prefix likewise.  We should still solve this problem.  While we're at
> it, I'd like to tackle bug #473598 [1] at the same time.

Not so! Any USE flags that are globally masked or forced are in the 
implicit-iuse list. Or is that what you meant as the hack? I think it's 
specified somewhere.

> Anyway, I was thinking more along the lines of using USE_EXPAND.
> There's also a USE_EXPAND_HIDDEN, and something like this [2] looks
> good.  

USE_EXPAND is fine too, it's just a special case of a USE flag, after all. It 
is perhaps more elegant than plain USE flags, and my plan was based on 
kernel_* and friends anyway.

> In other words, I could think of having EPREFIX="$classic" or 
> EPREFIX_TARGET="$rap", which could default to $classic in
> base/make.defaults.

It should default to "" in base/make.defaults. Only the prefix profiles should 
set it to anything nonempty.

-- Ruud

Re: [gentoo-alt] Names of Prefix variants

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 2006 bytes --]

On 26-10-2013 10:13:29 +0200, Ruud Koolen wrote:
> On Saturday 26 October 2013 09:41:28 Fabian Groffen wrote:
> > As you may or may not know, the prefix USE-flag is a hack that works in
> > Portage, but violates specifications, because it is never defined in
> > ebuilds that need it.  Discussions here go back to not wanting to show
> > elibc_XXX, kernel_XXX in IUSE (because user can't influence them) and
> > prefix likewise.  We should still solve this problem.  While we're at
> > it, I'd like to tackle bug #473598 [1] at the same time.
> 
> Not so! Any USE flags that are globally masked or forced are in the 
> implicit-iuse list. Or is that what you meant as the hack? I think it's 
> specified somewhere.

Last thing I understood, forcing it -- making it global -- is a Portage
behaviour, eapi-5 introduced some variable to define it or so.  So maybe
my entire comment is moot considering we aim for >=eapi-5.

> > Anyway, I was thinking more along the lines of using USE_EXPAND.
> > There's also a USE_EXPAND_HIDDEN, and something like this [2] looks
> > good.  
> 
> USE_EXPAND is fine too, it's just a special case of a USE flag, after all. It 
> is perhaps more elegant than plain USE flags, and my plan was based on 
> kernel_* and friends anyway.
> 
> > In other words, I could think of having EPREFIX="$classic" or 
> > EPREFIX_TARGET="$rap", which could default to $classic in
> > base/make.defaults.
> 
> It should default to "" in base/make.defaults. Only the prefix profiles should 
> set it to anything nonempty.

Have given this some thoughts, and maybe we need the global switch
whether or not prefix is enabled, and an additional features list to
select the variant of prefix (rap in this case).  Maybe that's complete
overkill, and your variant's nicer.  Anyway, a migration path or
backwards compatability is also important since use prefix is widely
adopted in gx86 nowadays...

Fabian

-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-alt] Names of Prefix variants

[heroxbd]

Fabian Groffen <grobian@gentoo.org> writes:

> On 26-10-2013 10:13:29 +0200, Ruud Koolen wrote:
>> On Saturday 26 October 2013 09:41:28 Fabian Groffen wrote:
>>> As you may or may not know, the prefix USE-flag is a hack that works in
>>> Portage, but violates specifications, because it is never defined in
>>> ebuilds that need it.  Discussions here go back to not wanting to show
>>> elibc_XXX, kernel_XXX in IUSE (because user can't influence them) and
>>> prefix likewise.  We should still solve this problem.  While we're at
>>> it, I'd like to tackle bug #473598 [1] at the same time.
>> 
>> Not so! Any USE flags that are globally masked or forced are in the 
>> implicit-iuse list. Or is that what you meant as the hack? I think it's 
>> specified somewhere.
>
> Last thing I understood, forcing it -- making it global -- is a Portage
> behaviour, eapi-5 introduced some variable to define it or so.  So maybe
> my entire comment is moot considering we aim for >=eapi-5.

USE prefix is a separate issue. Let's bring it to dev mailing list
afterwards.

>> > Anyway, I was thinking more along the lines of using USE_EXPAND.
>> > There's also a USE_EXPAND_HIDDEN, and something like this [2] looks
>> > good.  
>> 
>> USE_EXPAND is fine too, it's just a special case of a USE flag, after
>> all. It is perhaps more elegant than plain USE flags, and my plan was
>> based on kernel_* and friends anyway.
>> 
>> > In other words, I could think of having EPREFIX="$classic" or 
>> > EPREFIX_TARGET="$rap", which could default to $classic in
>> > base/make.defaults.
>> 
>> It should default to "" in base/make.defaults. Only the prefix profiles should 
>> set it to anything nonempty.
>
> Have given this some thoughts, and maybe we need the global switch
> whether or not prefix is enabled, and an additional features list to
> select the variant of prefix (rap in this case).  Maybe that's complete
> overkill, and your variant's nicer.  Anyway, a migration path or
> backwards compatability is also important since use prefix is widely
> adopted in gx86 nowadays...

classic and rap Prefix is matter of libc anyway.

How about a new USE flag as elibc_external? it's self-informative.
Define it on Linux variants of Prefix classic.

Then hacks in the ebuild can be written as

   if use prefix && use elibc_external then ...

The question is whether to define elibc_glibc at the same time,

by "grep elibc_glibc -r /usr/portage", one example of elibc_glibc is

   elibc_glibc? ( sys-libs/glibc )

where elibc_glibc should not be defined (at present we hack by adding
sys-libs/glibc:0 into package.provides) but another is

   $(use !elibc_glibc || echo --without-included-regex)

where elibc_glibc should be defined.

... It seems resonable to define elibc_external and elibc_glibc at the
same times.

Cheers,
Benda

Re: [gentoo-alt] Names of Prefix variants

[Michael Haubenwallner]

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

To distinguish between glibc/uclibc/etc, existing ELIBC could do.

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

My .02 $currency.

/haubi/

Re: [gentoo-alt] Names of Prefix variants

[Ruud Koolen]

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.

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

Re: [gentoo-alt] Names of Prefix variants

[Jeremy Olexa]

[-- Attachment #1: Type: text/plain, Size: 2682 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3388 bytes --]

Re: [gentoo-alt] Names of Prefix variants

[Michael Haubenwallner]

On 10/29/2013 11:02 PM, 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?

Actually 've read "prefix-native" to be the original Prefix without libc,
that is using the "native" libc, and have "prefix-libc" for RAP.

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

Have thought one inheriting the other is possible, but OK with me if not.

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

Trying to be conservative with new USE flags (along Jeremy's comment):

Any real counts already for the "handful of ebuilds" to benefit from having
"prefix-native" in addition to "prefix-libc" USE-flag?

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

Just a proposed implementation detail, without having tried out.

/haubi/

Re: [gentoo-alt] Names of Prefix variants

[Ruud Koolen]

Okay, this thread has been going nowhere for too long, and it's blocking 
progress. It's time to make a decision and be done with it.

I hereby christen the two variants of gentoo prefix "prefix guest" for the 
variant that has nongentoo include and library search paths and a nongentoo 
dynamic linker; and "prefix standalone" for which the dynamic linker and all 
search paths are strictly inside the prefix installation.

I will introduce a single new USE flag, masked in nonprefix profiles and 
forced in prefix guest profiles, "prefix-guest"; this USE flag with codify 
exactly the two properties specified above. I have decided not to use a 
second USE flag for the alternative after all; a look through the tree has 
shown that this would be useful at exactly one place (toolchain.eclass) and 
nowhere else, and at that point it's just a waste of complexity.

I will not use a USE_EXPAND variable, because there isn't really a (relevant) 
single setting that can take on multiple values across different prefix 
variants; rather, there is just the single deviation from normal gentoo 
system setups which may or may not apply to a given prefix variant, so a 
simple USE flag saying "this 'feature' is in effect" is the appropriate tool 
for the job.

I will create profiles default/linux/$arch/13.0/prefix/{guest,standalone}, of 
which the first is a link to prefix/linux/$arch and the second is the new 
profile to be written. I will not for now name either the "default" prefix 
profile on linux archs per the name default/linux/$arch/13.0/prefix, as I 
think that choice is best delayed until after we have more experience with 
how well the two variants work in practice; naming one the default is easy, 
but changing this decision later on is hard without breaking compatibility. 
Thus, for now default/linux/$arch/13.0/prefix will stay empty.

I will create a common base for the two variant profiles in features/prefix, 
with both variant profiles inheriting it. After all, the majority of profile 
hacks in the current prefix profiles would apply in full force in 
prefix-standalone.

Unless there are any complaints, I'm planning to make all this a reality in a 
few days.

Thoughts?

-- Ruud

Re: [gentoo-alt] Names of Prefix variants

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

On 18-11-2013 05:28:33 +0100, Ruud Koolen wrote:
> I will create a common base for the two variant profiles in features/prefix, 
> with both variant profiles inheriting it. After all, the majority of profile 
> hacks in the current prefix profiles would apply in full force in 
> prefix-standalone.
> 
> Unless there are any complaints, I'm planning to make all this a reality in a 
> few days.

I guess you did think about this, but just to be sure; you do make sure
non-Linux profiles will keep on running fine, right?  Also, the proposed
solution allows to do the same on non-Linux platforms too, right (e.g.
SCU on Darwin).

Thanks,
Fabian

-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [gentoo-alt] Names of Prefix variants

[Ruud Koolen]

On Monday 18 November 2013 10:24:46 Fabian Groffen wrote:
> On 18-11-2013 05:28:33 +0100, Ruud Koolen wrote:
> > I will create a common base for the two variant profiles in
> > features/prefix, with both variant profiles inheriting it. After all, the
> > majority of profile hacks in the current prefix profiles would apply in
> > full force in prefix-standalone.
> >
> > Unless there are any complaints, I'm planning to make all this a reality
> > in a few days.
>
> I guess you did think about this, but just to be sure; you do make sure
> non-Linux profiles will keep on running fine, right?

Of course.

> Also, the proposed solution allows to do the same on non-Linux platforms
> too, right (e.g. SCU on Darwin).

I have no idea what SCU is, but the proposed solution allows a standalone 
variant profile on any system for which we have a libc.

-- Ruud

Re: [gentoo-alt] Names of Prefix variants

[heroxbd]

Ruud Koolen <redlizard@gentoo.org> writes:

>> Also, the proposed solution allows to do the same on non-Linux platforms
>> too, right (e.g. SCU on Darwin).
>
> I have no idea what SCU is, but the proposed solution allows a standalone 
> variant profile on any system for which we have a libc.

In principle, yes. Somebody needs to succeed in compiling it
though[1,2].

Fabian, do you mean SFU[3]? It's deprecated by Microsoft.
Michael(haubi) and Markus(mduft) refocused the development to cygwin
instead, I suppose.

1. http://stackoverflow.com/questions/7592069/how-to-build-apples-opensource-libc
2. http://www.ohloh.net/p/glibc-darwin
3. http://en.wikipedia.org/wiki/Windows_Services_for_UNIX

Re: [gentoo-alt] Names of Prefix variants

[Michael Haubenwallner]

On 11/19/2013 11:20 AM, heroxbd@gentoo.org wrote:
>>> Also, the proposed solution allows to do the same on non-Linux platforms
>>> too, right (e.g. SCU on Darwin).

> Fabian, do you mean SFU[3]? It's deprecated by Microsoft.
> Michael(haubi) and Markus(mduft) refocused the development to cygwin
> instead, I suppose.
> 
> 1. http://stackoverflow.com/questions/7592069/how-to-build-apples-opensource-libc
> 2. http://www.ohloh.net/p/glibc-darwin
> 3. http://en.wikipedia.org/wiki/Windows_Services_for_UNIX

It wasn't us doing the Cygwin port - AFAICT Cygwin still isn't stable enough. But we're
currently working with Microsoft to find a way again to use the Microsoft toolchain in
some POSIX environment as replacement for SFU/SUA, which indeed has been finally thrown
away with Windows Server 2012r2 (it has been unstable since Windows Server 2008 anyway).

/haubi/

Re: [gentoo-alt] Names of Prefix variants

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

On 19-11-2013 19:20:38 +0900, heroxbd@gentoo.org wrote:
> Ruud Koolen <redlizard@gentoo.org> writes:
> 
> >> Also, the proposed solution allows to do the same on non-Linux platforms
> >> too, right (e.g. SCU on Darwin).
> >
> > I have no idea what SCU is, but the proposed solution allows a standalone 
> > variant profile on any system for which we have a libc.
> 
> In principle, yes. Somebody needs to succeed in compiling it
> though[1,2].
> 
> Fabian, do you mean SFU[3]? It's deprecated by Microsoft.
> Michael(haubi) and Markus(mduft) refocused the development to cygwin
> instead, I suppose.

No, I actually just meant something like "libc"[1] indeed... (but had
CSU in mind)

[1] http://www.opensource.apple.com/source/Libc/Libc-997.1.1/

 
> 1. http://stackoverflow.com/questions/7592069/how-to-build-apples-opensource-libc
> 2. http://www.ohloh.net/p/glibc-darwin
> 3. http://en.wikipedia.org/wiki/Windows_Services_for_UNIX
> 

-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [gentoo-alt] Names of Prefix variants

[heroxbd]

Hey Ruud,

Ruud Koolen <redlizard@gentoo.org> writes:

> I hereby christen the two variants of gentoo prefix "prefix guest" for the 
> variant that has nongentoo include and library search paths and a nongentoo 
> dynamic linker; and "prefix standalone" for which the dynamic linker and all 
> search paths are strictly inside the prefix installation.

Fine with me.

> I will introduce a single new USE flag, masked in nonprefix profiles
> and forced in prefix guest profiles, "prefix-guest"; this USE flag
> with codify exactly the two properties specified above. I have decided
> not to use a second USE flag for the alternative after all; a look
> through the tree has shown that this would be useful at exactly one
> place (toolchain.eclass) and nowhere else, and at that point it's just
> a waste of complexity.

Fine with me.

> I will not use a USE_EXPAND variable, because there isn't really a
> (relevant) single setting that can take on multiple values across
> different prefix variants; rather, there is just the single deviation
> from normal gentoo system setups which may or may not apply to a given
> prefix variant, so a simple USE flag saying "this 'feature' is in
> effect" is the appropriate tool for the job.

Fine with me, too.

> I will create profiles
> default/linux/$arch/13.0/prefix/{guest,standalone}, of which the first
> is a link to prefix/linux/$arch and the second is the new profile to
> be written. I will not for now name either the "default" prefix
> profile on linux archs per the name default/linux/$arch/13.0/prefix,
> as I think that choice is best delayed until after we have more
> experience with how well the two variants work in practice; naming one
> the default is easy, but changing this decision later on is hard
> without breaking compatibility.  Thus, for now
> default/linux/$arch/13.0/prefix will stay empty.

> I will create a common base for the two variant profiles in features/prefix, 
> with both variant profiles inheriting it. After all, the majority of profile 
> hacks in the current prefix profiles would apply in full force in 
> prefix-standalone.

To rephrase, put the greatest common divisor of {guest,standalone} to
features/prefix, with default/linux/$arch/13.0/prefix inheriting it.

> Unless there are any complaints, I'm planning to make all this a reality in a 
> few days.

Great! Let's stick to this plan and get it DONE.

Cheers,
Benda