1 |
On Sat, Dec 20, 2008 at 03:43:05PM +0000, Penguin Lover Stroller squawked: |
2 |
>> libdvdnav-4.1.3 is keyworded ~x86, while mplayer-1.0_rc2_p28058-r1 is |
3 |
>> keyworded x86. The USE cannot be satisfied. |
4 |
> |
5 |
> I'm really sorry, I don't understand. |
6 |
|
7 |
The dvdnav mask was added when the libdvdnav was hardmasked. But in |
8 |
this case, a similar reasoning applies. Basically: a package in stable |
9 |
should not depend on a package/package-version that is only available |
10 |
in testing; and that a package in stable/testing should not depend on |
11 |
a package that is only available if you manually keyword it. In other |
12 |
words, if you run a pure x86 system, you should never run into the |
13 |
problem where you try to emerge something and portage gives you an |
14 |
error that one of its dependencies cannot be installed because all |
15 |
packages satisfying that dependency is either hardmasked or keyworded |
16 |
~x86. |
17 |
|
18 |
To use your case as an example: if I run a purely x86 system. If the |
19 |
dvdnav flag is allowed, then if I try to emerge mplayer, it will try |
20 |
to install libdvdnav-4.1.3, and it will find that it is ~x86, which is |
21 |
not allowed on my system unless I manually keyword it. The portage |
22 |
tree is designed so that there should not be this kind of internal |
23 |
inconsistencies. |
24 |
|
25 |
In other words, if I decided to run a purely x86 system, a USE flag |
26 |
should not mandate that I keyword some particular packages in testing |
27 |
in order to install a package that is in stable. |
28 |
|
29 |
In general, the error message "The dependency blah/blah cannot be |
30 |
satisfied" should only appear if you have (1) keyworded a package but |
31 |
not all its dependencies or (2) a security bug caused an installed |
32 |
package to be hardmasked (think realcodec). |
33 |
|
34 |
> I manually keyworded libdvdnav-4.1.3 /etc/portage/package.use to make it |
35 |
> installable. |
36 |
> |
37 |
> It _is already_ installed. Doesn't that mean the USE is already satisfied? |
38 |
|
39 |
No. You are confusing how portage works. The problem is the USE cannot |
40 |
be satisfied for a pure x86 system. It can only be satisfied for a |
41 |
mixed or a ~x86 system. On this logic the USE is masked until it can |
42 |
be satisfied on a pure x86 system. So if libdvdnav goes stable, feel |
43 |
free to file a bug to remove the dvdnav USE-mask from the x86 profile. |
44 |
|
45 |
> I'm finding this a little confusing, having never dabbled this deep in |
46 |
> masking before. |
47 |
|
48 |
Don't blame you. AFAIK this is something not covered in the Gentoo |
49 |
Handbook. |
50 |
|
51 |
> I can the line you refer to in /usr/portage/profiles/base/package.use.mask, |
52 |
> it says: |
53 |
> media-video/mplayer cpudetection custom-cpuopts bindist dvdnav |
54 |
> |
55 |
> I assume this means "cpudetection custom-cpuopts bindist dvdnav" are "not |
56 |
> allowed" and that adding "-dvdnav" to my own mask would override that, |
57 |
> saying "-dvdnav" is not allowed, or "force dvdnav"? |
58 |
|
59 |
Yeah. I think of it as "removing dvdnav from the mask". Of course, |
60 |
notice that someone else pointed out my mistake: the file should be |
61 |
/etc/portage/profile/package.use.mask |
62 |
|
63 |
HTH, |
64 |
|
65 |
W |
66 |
|
67 |
-- |
68 |
A bunch of functions were sitting in a bar. |
69 |
|
70 |
Someone ran in and yelled, "the DIFFERENTIAL is coming!" And the |
71 |
entire bar scattered, except for one. |
72 |
|
73 |
The differential came in, looked him up and looked him down. The |
74 |
function replied with contempt: "I am e to the x!" |
75 |
|
76 |
The differential grinned: "I am d/dy." |
77 |
Sortir en Pantoufles: up 743 days, 16:38 |