I know the recent "User and group management via dedicated packages"'s draft (https://gentoo.org/glep/glep-0081.html) tried to not implie new development on the existing solution. However, it brings some annoying behaviour (in my opinion). When installing a package, for example: # emerge syncthing we now have to wait, then end up with this: [ Results for search key : syncthing ] * acct-group/syncthing Latest version available: 0 Latest version installed: [ Not Installed ] Size of files: 0 KiB Homepage: Description: Group for the system-wide net-p2p/syncthing server License: * acct-user/syncthing Latest version available: 0 Latest version installed: [ Not Installed ] Size of files: 0 KiB Homepage: Description: User for the system-wide net-p2p/syncthing server License: * net-p2p/syncthing Latest version available: 0.14.52 Latest version installed: [ Not Installed ] Size of files: 10,336 KiB Homepage: https://syncthing.net Description: Open Source Continuous File Synchronization License: MPL-2.0 [ Applications found : 6 ] !!! The short ebuild name "syncthing" is ambiguous. Please specify !!! one of the above fully-qualified ebuild names instead. so next step is: # emerge net-p2p/syncthing Can portage be smart enough to consider we want to install the package if we don't explicitly ask for installing the user or the group? A discussion is going on on the forum, pointing out that this as already been done for the category "virtual" (https://forums.gentoo.org/viewtopic-p-8359946.html#8359946).
While at it, let's make the list customizable. I'd love not to be bothered by dev-haskell or app-emacs name collisions.
(In reply to Michał Górny from comment #1) > While at it, let's make the list customizable. I'd love not to be bothered > by dev-haskell or app-emacs name collisions. Yeah, adjusting summary to reflect that. Meanwhile, current stable portage has a quick fix to handle the acct-* categories: https://gitweb.gentoo.org/proj/portage.git/commit/?id=44076b9432a1361a39515927de2b60baa2fbddb9
(In reply to Michał Górny from comment #1) > While at it, let's make the list customizable. I'd love not to be bothered > by dev-haskell or app-emacs name collisions. I wonder if it would make sense to implement this using wildcard package.mask atoms like */dev-haskell and */app-emacs for example?
(In reply to Zac Medico from comment #3) > (In reply to Michał Górny from comment #1) > > While at it, let's make the list customizable. I'd love not to be bothered > > by dev-haskell or app-emacs name collisions. > > I wonder if it would make sense to implement this using wildcard > package.mask atoms like */dev-haskell and */app-emacs for example? Wouldn't that imply that none of these packages would be installable as dependencies, though?
*** Bug 729752 has been marked as a duplicate of this bug. ***