| 1 |
Hi All, |
| 2 |
|
| 3 |
This is a continuation to |
| 4 |
|
| 5 |
http://article.gmane.org/gmane.linux.gentoo.alt/7083 |
| 6 |
|
| 7 |
Fabian wrote: |
| 8 |
|
| 9 |
> There once was a GLEP and all that, but I'm not sure it's reflecting |
| 10 |
> reality and all that. When the migration of Prefix to gx86 became |
| 11 |
> a thing, we made a decision. We used full keywords everywhere: arch-os, |
| 12 |
> gx86 used arch, just because it always was proper Gentoo Linux. |
| 13 |
|
| 14 |
|
| 15 |
The prefix-standalone (or RAP) is using its own libc independent of the |
| 16 |
host's. Most of the time, packages with ~ARCH keyword readily work on |
| 17 |
prefix-standalone, the failing cases only being the build system not |
| 18 |
respecting ${EPREFIX}. |
| 19 |
|
| 20 |
|
| 21 |
I propose that prefix-standalone (only, not prefix-rpath) taking an |
| 22 |
implicity keywording policy on linux, i.e. to accept both ~ARCH-linux |
| 23 |
and ~ARCH. |
| 24 |
|
| 25 |
|
| 26 |
Pros: |
| 27 |
|
| 28 |
- We save the time filing/resolving keyword request bugs and appending |
| 29 |
~ARCH-linux keywords. |
| 30 |
|
| 31 |
Cons: |
| 32 |
|
| 33 |
- A non-prefix-ready ebuild will not be masked and bite the |
| 34 |
prefix-standalone users. |
| 35 |
|
| 36 |
But I feel such packages are very few by now (need data to support |
| 37 |
this claim though). When that happens, we file a prefix-support |
| 38 |
bug. |
| 39 |
|
| 40 |
Any comments? |
| 41 |
|
| 42 |
Yours, |
| 43 |
Benda |
Archives