On Sat, Dec 20, 2008 at 03:43:05PM +0000, Penguin Lover Stroller squawked: >> libdvdnav-4.1.3 is keyworded ~x86, while mplayer-1.0_rc2_p28058-r1 is >> keyworded x86. The USE cannot be satisfied. > > I'm really sorry, I don't understand.
The dvdnav mask was added when the libdvdnav was hardmasked. But in this case, a similar reasoning applies. Basically: a package in stable should not depend on a package/package-version that is only available in testing; and that a package in stable/testing should not depend on a package that is only available if you manually keyword it. In other words, if you run a pure x86 system, you should never run into the problem where you try to emerge something and portage gives you an error that one of its dependencies cannot be installed because all packages satisfying that dependency is either hardmasked or keyworded ~x86. To use your case as an example: if I run a purely x86 system. If the dvdnav flag is allowed, then if I try to emerge mplayer, it will try to install libdvdnav-4.1.3, and it will find that it is ~x86, which is not allowed on my system unless I manually keyword it. The portage tree is designed so that there should not be this kind of internal inconsistencies. In other words, if I decided to run a purely x86 system, a USE flag should not mandate that I keyword some particular packages in testing in order to install a package that is in stable. In general, the error message "The dependency blah/blah cannot be satisfied" should only appear if you have (1) keyworded a package but not all its dependencies or (2) a security bug caused an installed package to be hardmasked (think realcodec). > I manually keyworded libdvdnav-4.1.3 /etc/portage/package.use to make it > installable. > > It _is already_ installed. Doesn't that mean the USE is already satisfied? No. You are confusing how portage works. The problem is the USE cannot be satisfied for a pure x86 system. It can only be satisfied for a mixed or a ~x86 system. On this logic the USE is masked until it can be satisfied on a pure x86 system. So if libdvdnav goes stable, feel free to file a bug to remove the dvdnav USE-mask from the x86 profile. > I'm finding this a little confusing, having never dabbled this deep in > masking before. Don't blame you. AFAIK this is something not covered in the Gentoo Handbook. > I can the line you refer to in /usr/portage/profiles/base/package.use.mask, > it says: > media-video/mplayer cpudetection custom-cpuopts bindist dvdnav > > I assume this means "cpudetection custom-cpuopts bindist dvdnav" are "not > allowed" and that adding "-dvdnav" to my own mask would override that, > saying "-dvdnav" is not allowed, or "force dvdnav"? Yeah. I think of it as "removing dvdnav from the mask". Of course, notice that someone else pointed out my mistake: the file should be /etc/portage/profile/package.use.mask HTH, W -- A bunch of functions were sitting in a bar. Someone ran in and yelled, "the DIFFERENTIAL is coming!" And the entire bar scattered, except for one. The differential came in, looked him up and looked him down. The function replied with contempt: "I am e to the x!" The differential grinned: "I am d/dy." Sortir en Pantoufles: up 743 days, 16:38
