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.
try to mask sys-libs/glibc should help if I got you right :)
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.
I would just like to second this suggestion.
portage cvs head handles this correctly already (we need a metabug btw for binding these together)...
*** This bug has been marked as a duplicate of 48195 ***