After emerge mpc -pv portage suggests only emerging dev-libs/mpc and ignores media-sound/mpc. It should report ambiguous results. Reproducible: Always Steps to Reproduce: 1.emerge mpc -pv Actual Results: [ebuild R ] dev-libs/mpc-0.9 0 kB Expected Results: Something like with emerge screen -pv but for mpc: [ Results for search key : screen ] [ Applications found : 2 ] * app-misc/screen Latest version available: 4.0.3-r4 Latest version installed: [ Not Installed ] Size of files: 820 kB Homepage: http://www.gnu.org/software/screen/ Description: Full-screen window manager that multiplexes physical terminals between several processes License: GPL-2 * app-vim/screen Latest version available: 1.4 Latest version installed: [ Not Installed ] Size of files: 12 kB Homepage: http://www.vim.org/scripts/script.php?script_id=2711 Description: vim plugin: simulate a split shell with screen or tmux License: public-domain !!! The short ebuild name "screen" is ambiguous. Please specify !!! one of the above fully-qualified ebuild names instead. ... done! Portage 2.1.10.7 (hardened/linux/amd64/selinux, gcc-4.5.2, glibc-2.13-r4, 2.6.39-hardened-r7 x86_64)
This is done BY DESIGN. Once an ambiguous atom is in your world file, then portage will consider that atom when you type it. Otherwise, when there is no ambiguous atom in your world file, portage can't guess which one you meant. I'm not a portage dev, so I will leave this bug open.
The automatic resolution of ambiguous names is definitely a feature, but I suppose we could trigger a brief warning message showing ambiguous matches in this case. You can always use emerge --search if you want a verbose display of ambiguous results.
pretty sure this is by design ... ambiguous atoms default to ones that are installed already
dev-libs/mpc is dependency of @system on my machine it is not in world file. It is added after emerge, which probably is ok with design, but I'm not sure if it the best thing to do. On the other hand while emerging stuff it is rather safe if not entirely expected behaviour, I think bigger problem is when unmerging it may lead to accidental removing of dev-libs/mpc when media-sound/mpc is already uninstalled, which in turn may lead to broken gcc (not sure if this is a case but gcc rdepends on it).
(In reply to comment #4) > dev-libs/mpc is dependency of @system on my machine it is not in world file. It > is added after emerge, which probably is ok with design, but I'm not sure if it > the best thing to do. When you don't use --oneshot, it's added to the world file only after the merge succeeds since if it fails for some reason there's not much point in recording it in the world file since it will get recorded once it finally does succeed (if ever). > On the other hand while emerging stuff it is rather safe if not entirely > expected behaviour, I think bigger problem is when unmerging it may lead to > accidental removing of dev-libs/mpc when media-sound/mpc is already > uninstalled, which in turn may lead to broken gcc (not sure if this is a case > but gcc rdepends on it). Well, --unmerge is always a risk. It will bail out if the name is ambiguous among those packages that are actually installed. You can protect yourself by using --ask, and --depclean <atom> will even check reverse dependencies for you (--unmerge already has a warning message which suggests to use --depclean).
sys-apps/portage-2.3.78-r2::gentoo seems to tell me if package I want to install/uninstall is ambigious, so I guess this can be closed.
