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. Reproducible: Always 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.
Would this dependency type do more than optfeature() from optfeature.eclass does? The only thing I can imagine is that it would record these dependencies in the VDB, but by comment #2 that wouldn't be desirable? I suggest to close this as WONTFIX.
Current eclass has some issues, for example as those in bug 892826: - Message will not be shown at update time but, subsequent depcleaning, will end up with the package uninstalled and the admin not being aware until an hypothetical future update - Another issue is that, maybe in 2023 a package was needed by a reverse "soft" dep, admin will install it. In the future, that package is no longer needed by that software... but the obsolete soft dep will stay installed even if not really wanted.
(In reply to Pacho Ramos from comment #6) It goes both ways. If optional dependencies aren't recorded, then there are the issues which you describe. OTOH if they are recorded, we'll have the problem mentioned in comment #2, i.e. optional deps like plugins will become hard to remove. Not sure whether both issues could be solved at the same time.
I am not sure about what system was thought originally... I was thinking them more like having two kinds of "world" files. Packages pulled in as "recommended" (I simply take the word use in Debian for this, I think RedHat/Mandriva were using something like "suggested") would be recorded in a different "world" file but in a way that they are kept there only if reverse deps are still pulling them. Maybe they could be stored in a format like: # parent package:suggested dependency app-office/lyx:dev-texlive/texlive-fontsextra Then, once user removes app-office/lyx or lyx ebuild stops having that suggested dep, texlive-fontsextra would be depcleaned. People would append lines to that "second level" world file in a similar way than "emerge --noreplace" does for regular world file: # emerge --install-recommended app-office/lyx:dev-texlive/texlive-fontsextra But it is only an idea... I don't know how this kind of deps are handled internally in yum or apt-get :S
You are reinventing USE flags, in a very complex, counter-intuitive and functionally limited way.
Well, current USE flags are not meant to be used for that, maybe this would be covered by the runtime switchable USE flags (I think they are suggested in bug 424283). I am happy with that approach too. But if you close this as a duplicate of that one, I would update its summary to mention "recommended/suggested" as most people will try to search for those concepts, because they are used in other package managers. Or you can make this bug depend on the runtime USEs :/
One recent headache I came across was sane-bacends. My device needed the hpaio backend which is provided by net-print/hplip-plugin[-minimal] which is a difficult guess.
(In reply to dE from comment #11) > One recent headache I came across was sane-bacends. My device needed the > hpaio backend which is provided by net-print/hplip-plugin[-minimal] which is > a difficult guess. Sorry, net-print/hplip[-minimal]
