Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 42334 - portage doesn't check /var/db/pkg for removed ebuilds
Summary: portage doesn't check /var/db/pkg for removed ebuilds
Status: RESOLVED DUPLICATE of bug 48195
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Conceptual/Abstract Ideas (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Brian Harring (RETIRED)
URL:
Whiteboard:
Keywords: InVCS
Depends on:
Blocks:
 
Reported: 2004-02-21 00:21 UTC by Andrew Johnson
Modified: 2005-11-20 19:02 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Johnson 2004-02-21 00:21:55 UTC
Short version:
I think portage should be smart enough to look in /var/db/pkg if
an ebuild no longer exists in portage.

Long version:
If one pins a particular version of a package using
/etc/portage/package.mask and the ebuild for that version of the
package is later removed from the portage tree, things break.

For a example, let's say I pinned glibc using the following line
in /etc/portage/package.mask sometime last year:
>sys-libs/glibc-2.3.1-r4

Thus glibc-2.3.1-r5 and higher are masked, and i've effectively
pinned myself at glibc-2.3.1-r4. Now, a number of months pass and
glibc-2.3.2-r9 is the current release.  glibc-2.3.1-r4.ebuild is
long removed from the portage tree. I'd still like to run an
emerge -up world without upgrading glibc, however. Let's say this
is a server and I just like to avoid upgrading glibc unless
absolutely necessary. emerge -up world would get me something
like this:
Calculating world dependencies ...done!
...
[ebuild     UD] sys-libs/glibc-2.2.5-r9 [2.3.1-r4]
...

Ok, so it wants to push me back to glibc-2.2.5-r9. This is
because glibc-2.3.1-r4 is no longer in the portage tree whereas
glibc-2.2.5-r9.ebuild was kept around.
The expected behavior here?  Don't touch glibc at all -- just
stick to the current version.

It seems to me that i have two main options here, both of which
are sort of workarounds:
1. Upgrade glibc (but I don't really want to do that)
2. Copy /var/db/pkg/sys-libs/glibc-2.3.1-r4/glibc-2.3.1-r4.ebuild
to my PORTDIR_OVERLAY. I've tested this to fix the problem in this
particular case.

In summary, I think portage should be smart enough to try looking
in /var/db/pkg if an ebuild no longer exists in the portage tree.



Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Comment 1 Sebastian Siewior 2004-05-16 06:56:04 UTC
try to mask 
sys-libs/glibc

should help if I got you right :)
Comment 2 Andrew Johnson 2004-09-07 21:28:50 UTC
I don't quite understand what you mean. By masking glibc altogether, this will will completely ruin dependency solving.

So, any comments on this? It still seems to me that portage should be smart enough to check /var/db/pkg for ebuilds that are no longer in portage.
Comment 3 Zack Pearsall 2005-01-02 09:50:03 UTC
I would just like to second this suggestion.
Comment 4 Brian Harring (RETIRED) gentoo-dev 2005-02-28 00:03:23 UTC
portage cvs head handles this correctly already (we need a metabug btw for binding these together)...
Comment 5 Jason Stubbs (RETIRED) gentoo-dev 2005-11-20 19:02:21 UTC

*** This bug has been marked as a duplicate of 48195 ***