Bug 60386

Summary:	emerge should consider /var/db/pkg/ as a fallback
Product:	Portage Development	Reporter:	Scott Dial <scott>
Component:	Enhancement/Feature Requests	Assignee:	Portage team <dev-portage>
Status:	RESOLVED WONTFIX
Severity:	minor
Priority:	High
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---

Description Scott Dial 2004-08-14 21:26:52 UTC

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:

Comment 1 Scott Dial 2004-08-15 01:32:08 UTC

I was reading through other emerge bug reports.. and I believe bug 42941 would be resolved by this change in behaviour.

Comment 2 Nicholas Jones (RETIRED) gentoo-dev

2004-09-21 18:23:41 UTC

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.