With the recent apache-2 and mysql-4 stable ebuilds there's been a lot of confusion on how to keep Gentoo from automatically upgrading those packages. It's simply a matter of adding an entry or two to /etc/portage/package.mask but since no /etc/portage directory exists by default on Gentoo, it's sort of a hidden feature. Shipping a blank /etc/portage/package.mask file(maybe with some comments in it on what it does) would help with this, as I think it would make the feature a little more obvious.
It's taken me a while to find this, I've been trying to work out how to have my own local masks. There's an einfo in the portage ebuild that says: "/etc/portage/profiles/package.mask is now /etc/portage/package.mask a hardlink has been created to the new location if it exists in profiles already." But there is no /etc/portage and no package.mask, as Mark says. This is a trivial bug to fix, you just need an insinto in the ebuild, and a file in /usr/portage/sys-apps/portage/files that says something along the lines of: # $Id$ # Use this file to mask packages that you do not want installed or upgraded # # Examples: # # Don't emerge any versions of mozilla later than 1.2: #>net-www/mozilla-1.2 # # Don't emerge xmms-1.2.7 only: #=media-sound/xmms-1.2.7 # And so on. Trivial fix, but necessary, I've wanted to do this for ages, as have others I know (who generally do it by adding their entries to /usr/portage/profiles/package.mask every time they emerge sync).
Some commented example files would be nice, the upcoming files in /etc/portage have no pendant in /usr/portage.
It was hidden on purpose. It's not intended to be a common method of masking. It's a feature that shouldn't be used unless the user knows what they are doing. If they don't figure it out, they probably won't know how to deal with the outcome should it be unfriendly.
Ok, then we can close this as well.
*** Bug 57402 has been marked as a duplicate of this bug. ***
Now that /etc/portage is the recommended way to mix stable/unstable packages (package.keywords), is it worth taking another look at this? I can understand wanting to hide the package.mask functionality originally, but making package.keywords slightly more obvious seems a better idea IMO than leaving people to try and work out how to do it themselves, which would lead people to use emerge -U on a regular basis. Since the latter has been deprecated in favour of this option, I'd suggest making it a bit more obvious.
