Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 46897 - Two init scripts with same 'provide' for a virtual dependency conflict
Summary: Two init scripts with same 'provide' for a virtual dependency conflict
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] baselayout (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo's Team for Core System packages
Keywords: InVCS
: 62778 156738 (view as bug list)
Depends on:
Blocks: 36060 140865
  Show dependency tree
Reported: 2004-04-05 14:45 UTC by Kevin Spicer
Modified: 2006-11-30 19:04 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---

patch to /etc/conf.d/rc (rc.patch,576 bytes, patch)
2004-04-05 14:46 UTC, Kevin Spicer
Details | Diff
patch to /sbin/ (,327 bytes, patch)
2004-04-05 14:47 UTC, Kevin Spicer
Details | Diff
patch to /lib/rcscripts/awk/gendepends.awk (gendepends.awk.patch,1.96 KB, patch)
2004-04-05 14:47 UTC, Kevin Spicer
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Spicer 2004-04-05 14:45:34 UTC
It's possible to install two (or more) packages where the init scripts provide the  same virtual dependency.  This causes 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/

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...
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.
Comment 1 Kevin Spicer 2004-04-05 14:46:34 UTC
Created attachment 28758 [details, diff]
patch to /etc/conf.d/rc
Comment 2 Kevin Spicer 2004-04-05 14:47:01 UTC
Created attachment 28759 [details, diff]
patch to /sbin/
Comment 3 Kevin Spicer 2004-04-05 14:47:50 UTC
Created attachment 28760 [details, diff]
patch to /lib/rcscripts/awk/gendepends.awk
Comment 4 GamesBond 2004-04-10 09:31:29 UTC
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 :)
Comment 5 SpanKY gentoo-dev 2005-11-27 10:16:23 UTC
*** Bug 62778 has been marked as a duplicate of this bug. ***
Comment 6 Chan Min Wai 2006-08-02 03:34:57 UTC
In Redhat there is something called


Where it let you select one of the few program which providing the same services.

Shouldn't that be some hints?

Comment 7 Roy Marples (RETIRED) gentoo-dev 2006-09-07 07:42:10 UTC
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 will not spit out any circular deps caused by the provides.

Well be in baselayout-1.13
Comment 8 Roy Marples (RETIRED) gentoo-dev 2006-10-16 06:20:37 UTC
baselayout-1.13.0_alpha1 is in portage, although p.masked

So this is finally fixed :)
Comment 9 Jakub Moc (RETIRED) gentoo-dev 2006-11-30 19:04:41 UTC
*** Bug 156738 has been marked as a duplicate of this bug. ***