Summary: | feature request: a way to keep a package installed that's been removed from the tree | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Danny <Dirus> |
Component: | Unclassified | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED DUPLICATE | ||
Severity: | enhancement | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Danny
2005-01-26 07:53:23 UTC
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. |