Mark Knecht <[email protected]> posted [email protected], excerpted below, on Tue, 27 Jan 2009 15:31:24 -0800:
> On Tue, Jan 27, 2009 at 3:08 PM, Sebastian Redl > <[email protected]> wrote: >> Mark Knecht wrote: >>> I seem to be a bit confused about the correct usage of ~amd64 vs >>> unmasking a package in the portage.unmask file. Thanks in advance. >>> >>> >>> What's the proper way for me to limit glib at the currently installed >>> revision level? >>> >>> >> portage.unmask is for masking, portage.keywords for keywording. These >> are not the same. >> >> You can accept the ~amd64 keyword for just a single version the same >> way you can unmask just a single version. Put this in portage.keywords: >> >> =dev-libs/glib-2.18.4 ~amd64 >> >> >> Sebastian > > Thank you Sebastian. That worked fine. > > Now, the same thing didn't work for portage-2.2_rc23. For that one I > actually had to add it to portage.unmask also. I think that's because > it's actually hard masked? Is that correct? Yes, that's correct. Really, Gentoo has four levels of masking available to devs to use, depending on what they think is appropriate. Three of these are keyword masks (one stronger than another), the other is hard mask. A really new package may be masked three of the four ways. It may have no keywords at all, plus be hard-masked in the main profiles/package.mask file. As it becomes clear that it can work on the various archs, it will get ~arch keywords for each where it is known to work at all. Also, new versions of packages that had previously known to work on an arch versions will usually start as ~arch masked. ~arch (for whichever arch, ~amd64, ~x86, etc) means the upstream package version is known to work on a particular arch, and is reasonably stable such that it's a "Gentoo stable candidate", but that there may still be problems with the ebuild itself (as opposed to the upstream package), or problems between it and other Gentoo stable packages that need to be resolved before it can go stable. Also, if one or more of a package's dependencies remain unstable, the ebuild itself cannot be stablized until all its dependencies are stable. Conversely, if a package is tested and is now known NOT to work on a particular arch, and that isn't likely to change, a -arch (as in -amd64, -x86, etc) keyword may be used. This may be used for instance if the package only works on little-endian systems such as x86 and amd64, but not on big-endian systems such as ppc. An x86 binary-only package would likely be marked -mips, etc, but not -amd64, since multilib will probably allow it to run there. Once all potential problems have been resolved (including all dependencies are stable) and there are no open bugs on a particular version for, typically, 30 days, it can go arch-stable, that is, keyword x86, amd64, etc. That covers three of the four types, all keyword related, no-keyword, ~arch, and -arch, plus arch-stable. The fourth type of masking is called hard-masking. That's an entry in the package.mask file either for everyone (in profile/package.mask) or for specific profiles (nomultilib profiles will have 32-bit x86-only binaries masked, as they require multilib). Typically, this is used for entirely inappropriate for stable packages, say the KDE-4.0 packages, because it was simply too immature yet to ever go stable, and for otherwise stable packages that are found to have security issues, etc. To see what versions of a package are available, period, along with their keywording and mask status, you can use the epkginfo <pkg> command. If you know a version exists in the tree (or an overlay you have active) and you wish to see why portage isn't considering it for merging, use emerge --pretend =<pkg-ver> or a variant such as a slot (gcc:4.2 for the 4.2 slot of gcc, for instance). Two things to note: One, if you have a package listed in package.unmask, it won't matter which package.mask file it's listed in (the main profiles/ package.mask, another package.mask file in your cascading profile, or your own package.mask in /etc/portage), that will hard-unmask (but not change the keyword status of, so it may still be keyword masked) that package. package.unmask therefore overrides all package.mask files including your own, and you need to be careful with it, because it'll override security masks as a result. Two, if for some reason you want to try a package that isn't keyworded for your arch at all, you can use the ** keyword in package.keyword. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
