I think it'd be very useful to be able to specify a version you do not want to downgrade past. Package.keywords works some of the time, but it is not entirely sufficient for this. Perhaps package.keywords could be changed to handle specific versions of ebuild better, or there could be something added like package.minimum. Example 1: I had to install ~x86 baselayout for the wireless stuff. After testing a couple ~x86 baselayout versions I found a version that worked well. I listed it in package.keywords and thought I could just wait for x86 (stable) to pass the version I settled with before upgrading. However when the ebuild was removed from portage it then asked me to downgrade. If I continue to upgrade to latest ~x86 when this happens I'll never get back to x86. Example 2: My job required me to use Eclipse 3, I settled with a version that worked for what I needed and listed it in package.keywords. When the ebuild was removed I was hounded by portage to downgrade. I couldn't very well mess with something like that mid project and until I finished I had to ignore it and upgrade everything else listed with "emerge -uD world" using the --oneshot keyword. Example 3: Some people on the forum were having trouble with his virtuals. Some people recommended upgrading to latest ~arch portage. This was before the big bump 2.0.51. When they found out they couldn't downgrade, concern was expressed that they would have to continously check the forums to find out when they were safely able to downgrade to the arch version of portage. Reproducible: Always Steps to Reproduce:
use /etc/portage/package.keywords `man portage`
I mentioned the problem with package.keywords. It doesn't work for =ebuild-version when the ebuild has been removed.
Copy it to your overlay? I suppose the problem is that the files are missing when you actually want them... You can fetch them through viewcvs at the moment... The most direct/simplist method right now might be copying the ebuild from your /var/db/pkg/ tree... The problem is the files/ directory.
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;)
Reopening for duping.
*** This bug has been marked as a duplicate of bug 48195 ***
Why is my 2 year old bug a duplicate of a bug that's 6 months old? Reading over the other bug, I also don't see how they are related. Does the fix for that bug happened to also fix this bug? I'm guessing this was just a mistake?
(In reply to comment #7) > Why is my 2 year old bug a duplicate of a bug that's 6 months old? Your original description in comment #0 is a little fuzzy. Can you suggest how we should implement a solution to your problem(s)? Perhaps this bug is a duplicate of bug 126059 or maybe that's a possible solution to one or more of your perceived problems?
>Your original description in comment #0 is a little fuzzy. Can you suggest how we should implement a solution to your problem(s)? The problem I tried to describe is that once the ebuild leaves the portage directory structure, the package.keywords file can no longer specify that ebuild (even if it matches, and matched before) and portage will try to get you to downgrade rather than realizing your current ebuild fits the bill. This is both a problem when it's a dependency, and when you just want to upgrade world. A simple solution would be, during the upgrade/dependency check, to look for installed ebuilds and not just those currently in the portage directory. The solution I was originally looking for was a way to go from ~x86 back to x86 on a couple ebuilds without downgrading, but rather by just holding the current ~arch version till the stable arch catches up. This "feature request" doesn't seem necessary if the underlying problem is fixed. Perhaps bug 48195 fixes exactly this, but it didn't sound related and I'm running amd64 so my current version is 2.1.1. I've been burned by updating to the ~arch version portage before so I'm a bit weary to try it myself.
Bug 126059 would seem to be in the same spirit as this bug. It was probably even opened for the same reason, but it seems like the wrong solution. Simply saving old ebuilds is dangerous or useless at best. The Manifest, file in the files sub-dir, and the digests would seem to change too often to make an old ebuild useful for much.
