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