[gentoo-amd64] Re: ~amd64 vs portage.unmask

[Duncan]

Mark Knecht <markknecht@×××××.com> posted
5bdc1c8b0901271531q5fe91aa9nc10e7202e3300b06@××××××××××.com, excerpted
below, on  Tue, 27 Jan 2009 15:31:24 -0800:

> On Tue, Jan 27, 2009 at 3:08 PM, Sebastian Redl
> <sebastian.redl@×××××××××××.at> 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