1 |
Norberto Bensa schreef: |
2 |
> Nick Rout wrote: |
3 |
> |
4 |
>>ACCEPT_KEYWORDS has been deprecated for a very long time. |
5 |
> |
6 |
> |
7 |
> But you can still use ACCEPT_KEYWORDS in /etc/make.conf if you want the whole |
8 |
> system to be ~x86. Or is there a better/recommendable way? |
9 |
> |
10 |
|
11 |
Yes, ACCEPT_KEYWORDS is a valid variable name for /etc/make.conf. |
12 |
|
13 |
It is just deprecated for "on-the-fly" usage, as follows: |
14 |
|
15 |
ACCEPT_KEYWORDS="~arch" emerge whatever |
16 |
|
17 |
The above is a very bad thing to do, and not because of some judgement |
18 |
call, but because it will cause you nothing but grief in the future. |
19 |
|
20 |
If you do something like that, the problem is that Portage will *not* |
21 |
remember that you authorized ~arch for "whatever" and the dependencies |
22 |
of "whatever", because you didn't authorize it, which authorization is |
23 |
carried out in /etc/make.conf for global settings, or |
24 |
/etc/portage/package.keywords for individual applications-- all you did |
25 |
was hack Portage temporarily to allow this app through its gateway. |
26 |
|
27 |
So when you next do an emerge world (or an emerge whatever), Portage |
28 |
will become horribly upset that there is an ~arch package installed, |
29 |
when it knows that all that is allowed are the stable arch packages. |
30 |
|
31 |
So it will downgrade "whatever" to stable. It may or may not downgrade |
32 |
the dependencies to stable, or may only dowgrade some of them. Which is |
33 |
all very well and good (unless of course you really wanted the unstable |
34 |
version), until you do another emerge -D world, and one of the unstable |
35 |
dependencies which was not downgraded, or was now marked stable (making |
36 |
it OK), wants to upgrade "whatever" again (because it is a dependency of |
37 |
"whatever version 2" not the "whatever version 1.5" you have installed), |
38 |
which will attempt upgrade whatever, but will then be forced to |
39 |
downgrade it immediately thereafter (because whatever version 2 is still |
40 |
not allowed on the system). |
41 |
|
42 |
Trust me, it's extremely ugly and totally not worth it. |
43 |
|
44 |
If you want to unmask a specific package without going to ~arch totally, |
45 |
add the package, and its dependencies if necessary, to |
46 |
/etc/portage/package.keywords. It's a bit more trouble at the start, but |
47 |
a lot less trouble in the end than using ACCEPT_KEYWORDS in an emerge |
48 |
command, unless you really mean to only *actively* test whether you want |
49 |
the unstable version of the package. |
50 |
|
51 |
In that case, it is useful, because if you find you don't want the |
52 |
package, Portage will downgrade it automatically for you (or you can do |
53 |
it yourself, in either case, Portage will not get all confused), and if |
54 |
you do want it, you can then add the authorization to |
55 |
/etc/portage/package.keywords, so Portage knows to keep it. |
56 |
|
57 |
HTH, |
58 |
Holly |
59 |
-- |
60 |
gentoo-user@g.o mailing list |