After a recent Portage update, I got a warning message that the default-x86-2004.2 profile was obsolete, and that I should switch to the default-linux/x86/2004.2 profile instead. After I did that, Portage tried to install vanilla-sources for me, even though I already had gentoo-sources installed. I suspect that this is because the new profile uses vanilla-sources for virtual/kernel, whereas the the old profile used linux-headers. While I have your attention, could someone please explain to me the intended differences between virtual/kernel, virtual/linux-sources, and virtual/os-headers? Shouldn't installing something like gentoo-sources provide all 3 of them? Also, why do the kernel and kernel-2 eclasses only have the HEADERS provide virtual/kernel? Thanks. Reproducible: Always Steps to Reproduce: 1. Update profile to default-linux/x86/2004.2 or default-linux/x86/2004.3. 2. Have Gentoo-Sources intstalled. 3. Emerge will still try to install vanilla-sources when you update.
Portage devs, is this a portage issue?
no, it's either a profile issue, a kernel eclass/ebuild problem or user error.
*what* were you trying to emerge such that vanilla-sources wasnt being pulled in ?
Sorry if I wasn't being clear: I have gentoo-sources installed. After I switched my profile to 2004.3, emerge -puD world ALSO tries to merge vanilla-sources. It shouldn't, since I already have gentoo-sources installed. Here is what I think the problem is: the 2004.3 profile needs virtual/kernel. The 2004.3 profile (in default-linux/virtuals) proclaims that vanilla-sources provides virtual/kernel. However, gentoo-sources does NOT provide virtual/kernel. Thus, Portage tries to merge vanilla-sources as well. Furthermore, I think the problem can be traced back to the kernel/kernel-2 eclasses. They both have the following logic: if etype = sources then provide virtual/linux-sources else if etype = headers then provide virtual/kernel and virtual/os-headers I don't think this logic is correct, since something like gentoo-sources would provide all three things.
no, the profile does not require virtual/kernel the virtuals file just defines default virtual providers try deleting that virtual/kernel entry in the virtuals file and see what package is requiring virtual/kernel the logic in the eclasses is correct
What I mean is, vanilla-sources does not seem to actually provide virtual/kernel. It inherits from kernel.eclass, with etype = sources, so it only provides virtual/linux-sources (tell me if I'm reading the eclass wrong). Since vanilla-sources does not provide virtual/kernel, why is it set as the default provider for virtual/kernel?
virtual/kernel shouldnt be used anymore
This should be fixed now that vanilla-sources uses kernel-2.eclass
