For e.g. we take media-sound/audacious and we have it's plugin media-plugins/audacious-dumb, but during merge of audacious, portage does not have any feature by which it can tell the user the list of enhancements that media-sound/audacious can have by merge of other packages; for e.g. in this case media-plugins/audacious-dumb is an enhancement to media-sound/audacious but currently portage has no method to tell the user that such a plugin (or enhancement) is available.
This feature can be implemented by use of USE flags, i.e for this example, we can have a use flag 'plugin-dumb' which will pull media-plugins/audacious-dumb with audacious, i.e. we are using use flags to pull in packages which are an enhancement; however I heard that this is against Gentoo ebuild policies, so this feature might be combined with Bug 319849 and we might have separate group of USE flags called 'enhancements', this will not break ebuild policies.
However I know that if this feature is added after resolving of Bug 319849, then it will be done after 2012 but policies can be changed in days.
Take your pick. This is sort of like mimicking the --install-recommended feature of apt.
Steps to Reproduce:
The closest thing that you can do at this time is to produce an elog message in pkg_postinst. For example, that's the approach that I used for the suggested tarsync dependency in bug 264730.
The problem is, when user installs these enhancements it gets recorded into world favorite. So when you want to remove the main package --depclean returns an error and you have to remove the package manually. Cumbersome if there're lots of such plugins.
*** Bug 353845 has been marked as a duplicate of this bug. ***
On the wiki at: http://wiki.gentoo.org/wiki/Future_EAPI/New_dependency_types
this is defined as SDEPEND. I'd like to suggest UIDEPEND (or UDEPEND), with scope for a simple label (ie UIDEPEND="recommend:cat/pkg-plugin-foo suggest:cat/pkg-plugin-bar". imo the label should be required since one should think carefully about recommending a user installs something, and it makes parsing simpler, as well as being more transparent to the reader in the case where there is only one type of suggestion.)
Since this is not required during normal dependency calculation (but rather for the user-interface to suggest addition of a new package, after the normal calculation has been done, and given that a certain package has already been selected), and there is a requirement for more than one type of suggestion, (recommended and suggested/optional were discussed before), the extra complexity seems like less of an ask: it could only get triggered when the manager is displaying to the user, if s/he actually wants that to happen. There is no requirement that the information ever be utilised, by definition.
It would also appear to make sense to allow for future new types of user-interface suggestion, and confining them to one variable also makes sense, since they are not required for standard operation, and how they are acted upon is outside the scope of PMS.