It's possible to install two (or more) packages where the init scripts provide the same virtual dependency. This causes depscan.sh to complain and pick the fist one it encounters to satisfy the dependency. Currently the only solution to force depscan to pick the service you wish to satisfy the dependency is to unmerge the offending package or edit/delete the offending init script (which is not ideal as it will be replaced when upgrading) Reproducible: Always Steps to Reproduce: 1. Install two packages which provide the same virtual dependency (eg. sysklogd and syslog-ng) 2. run /sbin/depscan.sh Actual Results: Warned that one (or other) package already satisfied the dependency so ignored second one. Note that which one is chosen is not easily predictable Expected Results: Provide a mechanism for user to set a preference I will add three attachments to this bug when filed, these are to... /etc/conf.d/rc /sbin/depscan.sh /lib/rcscripts/awk/gendepends.awk These implement one possible solution by adding a variable to /etc/conf.d/rc which permits the user to specify virtual:real dependency pairs which will be used by preference if the real package reffered to is present.
Created attachment 28758 [details, diff] patch to /etc/conf.d/rc
Created attachment 28759 [details, diff] patch to /sbin/depscan.sh
Created attachment 28760 [details, diff] patch to /lib/rcscripts/awk/gendepends.awk
Would it be a solution to have selection of the correct package done automagically by looking at the users setting in rc-update? The package that is selected to start is the one to go with, the package that is disabled by default is ignored. It will not work for every package or setup but at least will catch most of them (like MailScanner). You must disable sendmail in rc-update and enable the sendmail script which invokes sendmail. Just my $0.02 :)
*** Bug 62778 has been marked as a duplicate of this bug. ***
In Redhat there is something called alternative. Where it let you select one of the few program which providing the same services. Shouldn't that be some hints?
Latest SVN Changelog in trunk It is now possible to have >1 service that can provide foo. If something then uses foo it selects which service to depend on using the following criteria - not stopped, in runlevel, alphabetical. :) The only downside of my approach is that depscan.sh will not spit out any circular deps caused by the provides. Well be in baselayout-1.13
baselayout-1.13.0_alpha1 is in portage, although p.masked So this is finally fixed :)
*** Bug 156738 has been marked as a duplicate of this bug. ***
