Consider "emerge -uaDv world" which ideally is going to update everything and downgrade any newly masked packages. Then, a user wants to avoid upgrading any further, in my case I didn't want to upgrade the kernel sources. So, the user adds ">sys-kernel/gentoo-sources-2.4.25-r2" to package.mask (or something similar) which should keep any future updates masked. This works.. for a while.. and then in the future gentoo-sources-2.4.25-r2 gets removed from portage, which then means the only unmasked package in portage that satisfies the masking is, let's say, gentoo-sources-2.4.24-rN or whatever the current revision of 2.4.24 that is available. Which then is going to 'cause emerge to downgrade the kernel. I use the kernel only as an example 'cause it is the package I noticed this with. I think, that /var/db/pkg should be considered as fallback.. if a package installed already that satisfies a dependancy, we shouldn't downgrade.. nor if we are updating everything, we shouldn't downgrade.. UNLESS there is an entry in portage that is masked (/usr/portage should always supercede /var/db/pkg). I am envisioning that there is a problem with this.. but I can't come up with a more effective way to get the intended behaviour of "protecting" a package. Reproducible: Always Steps to Reproduce:
I was reading through other emerge bug reports.. and I believe bug 42941 would be resolved by this change in behaviour.
What about eclasses? What about FILESDIR? You'd have to clone a lot of portage to maintain this state. It can be handled in another way. Brian Ferring has a large change to ebuild.sh which may accomodate things _like_ this, but I don't anticipate supporting this particular case.
