For whatever reason, the gentoo developers seem to throw everything into package.mask - though on some rare occasions, they'll use the ~x86, seemingly at random. I'd much rather have something else - `x86 perhaps - which is used for beta programs, in addition to the ~x86 for experimental ones.

Thus, to fix my problem, a couple months ago I got fed up enough. Every time I `emerge rsync', it replaces the package.mask file, which I had, of course, changed. Then, the several packages that I've unmasked are of course masked again, and the few masks that I added myself for packages that aren't working for me are removed. So, it made an `emerge rsync' a painstaking process - so I wrote a script called 'unmask', which simply had a big perl regular expression for unmasking packages, and a list of packages to add to the end of package.mask. After each emerge rsync, I'd just run my script and I'd have all the unwanted masks commented out, and all the wanted ones added back in.

It worked for me for a couple months (I unmask about 25 packages, and mask 8), until a friend of mine decided to write something much more sophisticated (it beats me as to why, since he just adds two masks, but he did). This new one is far more sophisticated in that it doesn't simply have a list of things in the file, as mine did, but it performs a merge of /usr/local/portage/profiles/package.mask and the /usr/portage/profiles/package.mask.

Since there is no way to attach a file to a post (hint, hint, forum maintainers), I've put it up here:

# depends on moz gtk2 which is not well tested yet
!>=net-www/galeon-1.3.2

The items with a leading ! indicate something for the script to unmask, otherwise the mask is added to the normal packages.mask file. What's interesting to note is this:

!>=sys-apps/baselayout-1.8.6.0

That does just what you expect it to do - it unmasks any baselayout mask that applies to 1.8.6.0 or above (thus actually unmasking 5 lines in the file).

Please download it, and give it a try - I saved it to /usr/local/bin/unmask, but anywhere in your path will work. If you use sudo, as I do, it'll let you run it as a user; otherwise you have to be root.

That's interesting, and you might want to write a report in bugzilla. It's the right place to propose improvments of portage._________________I may not agree with what you say, but I'll defend to the death your right to say it.

I've uploaded an updated version, with a few changes - such as comments, and I switched it to use '/usr/lib/portage/bin/portageq' instead of parsing 'emerge info' - but unfortunately it makes it slow because each call takes about half a second - on my Athlon 3000++ system. Nice fast Python.

As mentioned earlier, this would be very handy built into portage, perhaps as emerge --unmask sync, or just something it does as standard, though emerge sync && unmask works fine for now.

Given the direction Gentoo seems to be taking lately*, I doubt this will ever making it into emerge. A gentoolkit tool, perhaps, but emerge is doubtful.

* This is my feeling of late - developers are slow to release new or updated ebuilds, and experimental packages/releases are officially "BAD" - witness the CVS package purge, for example. ~x86 tends to be the "testing" phase of packages, rather than the "experimental" phase it was meant to be. Don't get me wrong - I still think Gentoo's above any other distribution, but it's losing some of the "cool" factor by going more mainstream in packages and development. I guess that's what happen when things get bigger.

However, I must say, I've been getting increasingly irritated at the fact that I'm unable to mask multiple (or even all) versions of specific packages myself. This should be very useful, and hopefully a little easier to work with than my rather confusing concatenation of sed-based shell scripts. Thanks!

However, I must say, I've been getting increasingly irritated at the fact that I'm unable to mask multiple (or even all) versions of specific packages myself.

With portage-2.0.48-*, you can create a custom mask file, named /etc/portage/profiles/package.mask. Syntax is the same as the /usr/portage/profiles/package.mask, think of it as if it was concatenate to the official mask (actually, it's nearly what is done). With portage-2.0.49_pre*, it should be named /etc/portage/package.mask, which is more consistent with the package.unmask.[/i]

The /etc/portage/package.{mask,unmask} files (2.0.49_pre) are pretty nice; I've stopped using the unmask script above in favour of them. It doesn't do everything the unmask script does, but it does what I need nontheless. I only wish it was documented somewhere (perhaps creating empty package.mask/unmask files with descriptive comments at the top) as to exactly what the files do (hint, hint).