I'm using ck-sources as my kernel. I just recently installed sys-kernel/ck-sources-2.6.10-r1. And it is running fine. Anyway, when I synced the portage tree, the ebuild for ck-sources-2.6.10-r1 was gone from the tree, replaced by 2.6.10-r2. I decided that I don't want to upgrade to -r2 now since there are only minor changes. So, I add the following into /etc/portage/package.mask: >=sys-kernel/ck-sources-2.6.10-r2 # to prevent newer versions <sys-kernel/ck-sources-2.6.0 # to prevent 2.4.x series Problem: Portage ignores the virtuals provided by my already-installed 2.6.10-r1 kernel sources! So, when I run the emerge -uvaD world, I get # emerge -uvaD --tree --newuse world These are the packages that I would merge, in reverse order: Calculating world dependencies ...done! [ebuild U ] media-sound/mpg123-0.59s-r9 [0.59s-r8] -3dnow -esd +mmx -nas -oss 246 kB [nomerge ] media-sound/alsa-utils-1.0.6 [nomerge ] media-libs/alsa-lib-1.0.7 -doc -jack -static [ebuild N ] media-sound/alsa-driver-1.0.7-r4 -debug -doc -oss 1,786 kB [ebuild N ] sys-kernel/gentoo-sources-2.4.26-r14 -build -doc 31,236 kB [nomerge ] sys-apps/man-pages-1.70 [nomerge ] sys-apps/man-1.5m-r2 -debug +nls [nomerge ] sys-apps/sed-4.0.9 -bootstrap -build -debug +nls -static [nomerge ] sys-libs/glibc-2.3.4.20040808-r1 -build -debug -erandom -hardened -multilib +nls +nptl +pic +userlocales [nomerge ] sys-apps/baselayout-1.9.4-r6 -bootstrap -build -debug -livecd (-selinux) -static (-uclibc) [ebuild U ] sys-kernel/linux26-headers-2.6.8.1-r2 [2.6.8.1-r1] -build 34,870 kB Total size of downloads: 68,139 kB Do you want me to merge these packages? [Yes/No] no If I remove the masking, I get the upgrade to -r2 and the virtuals problem disappears: # emerge -uvaD --tree --newuse world These are the packages that I would merge, in reverse order: Calculating world dependencies ...done! [ebuild U ] media-sound/mpg123-0.59s-r9 [0.59s-r8] -3dnow -esd +mmx -nas -oss 246 kB [nomerge ] media-sound/alsa-utils-1.0.6 [nomerge ] media-libs/alsa-lib-1.0.7 -doc -jack -static [ebuild NS ] sys-kernel/ck-sources-2.6.10-r2 -build -doc 48 kB [nomerge ] sys-apps/man-pages-1.70 [nomerge ] sys-apps/man-1.5m-r2 -debug +nls [nomerge ] sys-apps/sed-4.0.9 -bootstrap -build -debug +nls -static [nomerge ] sys-libs/glibc-2.3.4.20040808-r1 -build -debug -erandom -hardened -multilib +nls +nptl +pic +userlocales [nomerge ] sys-apps/baselayout-1.9.4-r6 -bootstrap -build -debug -livecd (-selinux) -static (-uclibc) [ebuild U ] sys-kernel/linux26-headers-2.6.8.1-r2 [2.6.8.1-r1] -build 34,870 kB Total size of downloads: 35,164 kB Do you want me to merge these packages? [Yes/No] no As can be clearly seen, the virtuals/alsa is not provided by my already-installed ck-sources. Note what I have in my package database: ck-sources-2.6.10-r1 # pwd /var/db/pkg/sys-kernel/ck-sources-2.6.10-r1 ck-sources-2.6.10-r1 # cat PROVIDE virtual/linux-sources virtual/alsa Steps to repeat bug (I think): 1. Install package that provides a virtual (that is needed by other packages) 2. Remove original ebuild from portage tree 3. Try to update world, installed virtual does not show up Steps to *definitely* repeat bug: 1. Get the ck-sources-2.6.10-r1 ebuild from CVS, install ck-sources 2. Resync portage tree 3. Mask other ck-sources packages besides the installed 2.6.10-r1 Workaround: Put the currently existing version into /etc/portage/package.provided.. Please fix.
Oh yeah, my portage version is Portage 2.0.51-r3 (default-linux/x86/2004.3, gcc-3.4.3, glibc-2.3.4.20040808-r1, 2.6.10-ck1 i686)
Can you mask and provide "emerge -uDp --debug world" output please?
Created attachment 47880 [details] Output of emerge -uDp --debug world Here you go, as an attachment instead of comment due to size.
This isn't a bug in dependency selection. If a package is not present in the tree, it is not valid for consideration as a valid package. Valid must be valid. Hence, if you want a virtual you must make it recognisible and a legitimate package for portage to choose.
Well, how about including the ebuilds of currently installed packages into the selection process? I mean, i still have /var/db/pkg/sys-kernel/ck-sources-2.6.10-r1/ck-sources-2.6.10-r1.ebuild and it works just fine as an ebuild. It provided virtuals when it was emerged. Just because the -r1.ebuild has been removed from the tree it should not mean that the virtuals provided by -r1 suddenly cease to exist. This was not a problem with the old-fashioned /var/cache/edb/virtuals-file, because it was changed only when emerging or unmerging stuff. In that system even ebuilds that get removed from tree were still "providing" virtuals. When I emerged kernel-sources, alsa was placed into the virtuals file and removed only if I unmerged the sources - not when the original ebuild vanished from the tree. I think this should be addressed, because there are some packages that might get "old" (removed from portage tree to clean it up periodically) but people still might not want to perform an upgrade. Kernels are probably the most prominent ones that come to mind - you don't want to reboot your server every other day to keep it running the latest kernel - but just because your current kernel version might get removed from the tree shouldn't make the virtuals it provides invalid. If this is not fixed, then what is the correct solution to this problem? Hacking around with package.provided and saying that you have a later version of a particular ebuild than you actually do? (Does this even work?)
I totally agree with Antti. This should be considered a bug or at least unwanted behaviour. In a production environment you may very well want to keep an updated tree but don't want to update all the packages all the time. One often heared comment from the Gentoo team, when people complain about old packages being removed, is that you don't have to upgrade just because the ebuild-tree does. Well, with this behavious you do, as your only choices are between an old tree or always updating as fast at the Gentoo developers. I'm working as a Systems Adminitrator at the Dept. of Computer Science at the University of Copenhagen, and this behaviour is current a bug problem for our serverpark. We have a policy not update certain groups of server during periods of about 3 month (keeping them stabil during courses), so we use hard-masking to "lock" to specific maximum version. However we do want to keep an updated ebuild-tree and be able to make specific critical updates. In short : A installed packages might be old, but it should at least stay valid in the dependency graph. Whether or not to upgrade should be up to the system administrator, not the Portage developer team.
Oh well. For the moment, I'll do as follows: emerge -C ck-sources echo sys-kernel/ck-sources >> /etc/portage/package.provided and manage my kernel-sources manually. If portage gets a fix I'll start using it again.
Great. Besides the fact that package.provided should be in /etc/portage/profile and not /etc/portage, this doesn't work. So, I followed the instructions and created my own local homebrew-sources according to these instructions: http://forums.gentoo.org/viewtopic.php?p=1932735#1932735 Works now, but this was quite a PITA. (And considering that I never wanted to start managing kernels myself, even more so - all I want is to keep my portage tree in sync while not upgrading kernels.)
This is happening *again*. This time, with dev-java/sun-jre-bin and providing of virtual/java. Because of the manual fetching procedure, I would prefer not to upgrade immediately. I have >=dev-java/sun-jre-bin-1.4.2.06 in my package.mask. I have sun-jre-bin-1.4.2.05-r1 installed. Now the ebuild for 1.4.2.05-r1 has vanished from portage tree - so now portage thinks I should install [ebuild N ] dev-java/blackdown-jre-1.4.2.01 -mozilla 14,380 kB In this case, unlike with the kernel sources, I really cannot use package.provided. Oh, and I upgraded portage to 2.0.51-r15, this issue was not fixed in that version.
Until Keywords gets the addition of "InCVS" and/or there's some notification on this bug, it won't be fixed. It will in fact be some time before it is fixed. As a workaround you can do something to the effect of: # mkdir -p /usr/portage/local/dev-java/sun-jre-bin # echo "PORTDIR_OVERLAY=\"/usr/portage/local\"" >> /etc/make.conf # cp /var/db/pkg/dev-java/sun-jre-bin-1.4.2.05-r1/sun-jre-bin-1.4.2.05-r1.ebuild /usr/portage/local/dev-java/sun-jre/bin This method is much better than using package.provided as that file is meant to be used to tell portage about software which is installed and managed *outside* of portage.
Thanks Jason, that's a good idea. I'll do that.
*** This bug has been marked as a duplicate of 48195 ***
