| 1 |
On 08/05/2011 05:13 PM, heroxbd@×××××.com wrote: |
| 2 |
> Dear Zac, |
| 3 |
> |
| 4 |
> Zac Medico <zmedico@g.o> writes: |
| 5 |
> |
| 6 |
>> This is totally unnecessary, since you can use |
| 7 |
>> $EPREFIX/etc/portage/package.accept_keywords for these. |
| 8 |
> |
| 9 |
> Ah-ha, from GLEP22[1], e.g. ~amd64 is a default to ~amd64-linux. Why |
| 10 |
> don't we just treat these reasonable defauls as equal in the portage? |
| 11 |
|
| 12 |
You can configure that yourself by setting ACCEPT_KEYWORDS="~amd64 |
| 13 |
amd64" in make.conf. |
| 14 |
|
| 15 |
However, it's not generally recommended since when ~amd64-linux is |
| 16 |
missing from KEYWORDS it means that it may not have been tested in a |
| 17 |
amd64-linux prefix environment. Sometimes it will work, but it's also |
| 18 |
common for such ebuilds to try and install files outside of $EPREFIX |
| 19 |
which will cause them to abort before they are installed. |
| 20 |
|
| 21 |
Also, if you use package.accept_keywords along with --autounmask-write, |
| 22 |
then you'll have a list of packages that is convenient if you plan to |
| 23 |
submit keyword requests. |
| 24 |
|
| 25 |
> I see bugs (and submit myself) in bugzilla to add keywords as |
| 26 |
> ~amd64-linux when there is already ~amd64. Wondering the motivation of |
| 27 |
> doing it explicitly. |
| 28 |
|
| 29 |
In order to indicate that it has been tested in a prefix environment, |
| 30 |
versus a non-prefix environment. |
| 31 |
-- |
| 32 |
Thanks, |
| 33 |
Zac |
Archives