| Summary: | /etc/portage/profile/virtuals should allow selection between installed providers of virtual/alsa | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Mark Purtill <gentoo> |
| Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | Keywords: | InVCS |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | virtuals-selection.patch | ||
|
Description
Mark Purtill
2004-12-21 11:00:36 UTC
Hi, [ebuild NS ] media-sound/alsa-driver-1.0.7-r4 This means you already have another version of alsa-driver installed, right? /etc/portage/profile/virtuals works for me (with portage 2.0.51-r3 and 2.0.51-r8 both), but it only affects the default package to provide a virtual. If a virtual is already provided by another package, portage keeps using that. That's correct behaviour according to the documentation. However, for some reason, /etc/portage/virtuals will override this (I tested it with virtual/x11 and x11-base/xfree, while I have xorg-x11 installed). That, again according to the documentation, *is* a bug, but it's what you're hoping won't be fixed. Please let me know if I misunderstand something. Yes, I want alsa-dirver to be installed for the 2.4 kernels. But I don't understand what you mean by "if a virtual is already provided by another package, portage keeps using that". The virtual is provided by multiple installed packages (alsa-driver and the gentoo-dev-sources), so why does portage think alsa-driver is the one providing it and not gentoo-dev-sources? I thought the whole point of /etc/portage/profile/virtuals was to let me tell it which one I want it to consider being used. If all it does is what you say (and 'man portage' does say that), it seems to me to be pretty useless---I can just install the one I want, so what good is having an obscure file to tell portage to do that for me? "The virtual is provided by multiple installed packages (alsa-driver and the gentoo-dev-sources), so why does portage think alsa-driver is the one providing it and not gentoo-dev-sources?" It does this because there is not normally any reason to check if any other packages provide it as well. Normally, virtual/xxx is only used as a dependency, and when multiple packages provide the same virtual, there is (in that situation) no reason to check which package provides it, only that it's provided. If you don't mind me asking, why do you want to pass it as an argument to emerge directly? "I thought the whole point of /etc/portage/profile/virtuals was to let me tell it which one I want it to consider being used. If all it does is what you say (and 'man portage' does say that), it seems to me to be pretty useless---I can just install the one I want, so what good is having an obscure file to tell portage to do that for me?" It can be useful with injected packages (via emerge --inject or package.provided). For example, on my system, I added my kernel sources to /etc/portage/profile/package.provided, because I didn't use portage to install them. That doesn't tell portage I have virtual/alsa already. To solve that, I used /etc/portage/profile/virtuals to tell portage to use the kernel sources by default for that. ASorry, I should have said in the original bug report. The original problem was that "emerge world" was attempting to emerge alsa-driver and stopping, preventing me from continuing the emerge (without hand intervention). I mentioned "emerge virtual/alsa" to demonstrate what was causing the problem. But because everything else is now up-to-date, I can no longer reproduce the problem that way. So I used "emerge virtual/alsa" in the bug report because it still tries to emerge alsa-driver (and is much easier to reproduce). Anyway, since emerge is doing the intended thing, I've changed the title to "/etc/portage/profile/virtuals should allow selection between installed providers of virtual/alsa" and changed the severity to "enhancement". (One actual bug is that "man portage" still refers to /etc/portage/virtuals, not /etc/portage/profile/virtuals.) Created attachment 46743 [details, diff]
virtuals-selection.patch
"Sorry, I should have said in the original bug report. The original problem
was that "emerge world" was attempting to emerge alsa-driver and stopping,
preventing me from continuing the emerge (without hand intervention)."
Then, masking newer versions of alsa-driver would probably be a better idea.
But really, it's your system. This patch (against 2.0.51-r8) should do it. I
tested it with virtual/editors, with nano, gvim and vim all installed.
"Anyway, since emerge is doing the intended thing, I've changed the title to
"/etc/portage/profile/virtuals should allow selection between installed
providers of virtual/alsa" and changed the severity to "enhancement"."
This patch (for me) doesn't noticeable slow down portage, and I don't believe
it would break anything. However, it could be a real pain to keep supporting it
if some functions are rewritten in later versions of portage, and it's only
rarely useful, so perhaps it would be better to modify portage only on your
local system. But that, of course, is completely the portage devs' choice :)
"(One actual bug is that "man portage" still refers to /etc/portage/virtuals,"
I don't believe that's a bug, since portage still supports it (with a
deprecation notice, but still). However, either the description for
/etc/portage/virtuals is inaccurate, or the implementation is buggy, as
explained earlier.
"not /etc/portage/profile/virtuals.)"
It does describe that. /etc/portage/profile/ is described as "site-specific
overrides of /etc/make.profile/", and /etc/make.profile/virtuals is described.
An additional comment, I have emacs, vim and nano installed on my system, they all provide virtual/editor, but when I do emerge -e system (after upgrading gcc) portage wants to use emacs to satisfy the dependency. Since emacs depends on gnome and xorg lots of packages are remerged, when a better alternative would be to only remerge nano. The only way I've found to fix this is to either use the patch above or the deprecated /etc/protage/virtuals file. /etc/portage/virtuals and /etc/portage/profile/virtuals have now been unified. Those files now override the profile in the same way that /etc/portage/prfoile/virtuals was doing already. Installed virtual-providing packages are then discovered and put in the same order as the stacked profile listing. This essentially means that /etc/portage/profile/virtuals can be used to both specify defaults and select among installed virtuals. Also: Maybe /usr/lib/portage/bin/fixvirtuals should also update the virtuals at the right location, not /var/lib/dep/virtuals I think? This is fixed in 2.0.51.19. The fixvirtuals scripts is outdated and doesn't apply to any of the 2.0.51 range. It will be removed on the next release. |
