Bug 147184 - symbolic links (e.g. /etc/rc0.d) with multiple providers
Summary: symbolic links (e.g. /etc/rc0.d) with multiple providers
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: initscripts   
(Show other bugs)
Version: 3.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2005-02-04 18:42 UTC by Joe Keller
Modified: 2014-03-17 02:52 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-04 20:27:18 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Joe Keller 2005-02-04 18:42:01 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

Description of problem:
Both the initscripts and chkconfig provide the following symbolic 
  /etc/rc0.d, /etc/rc1.d, /etc/rc2.d, /etc/rc3.d, /etc/rc4.d,
  /etc/rc5.d, /etc/rc6.d

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.rpm -qf /etc/rc0.d

Actual Results:  [root@wrx root]# rpm -qf /etc/rc0.d

Expected Results:  Only one file should be listed.

Additional info:

Comment 1 Bill Nottingham 2005-02-04 20:27:18 UTC
There's a reason for this; in fact, they were only owned by one for a
brief period back in 2000, before it was added back. Unfortunately,
the specifics of the reason are escaping me.

I don't think that this causes any functional problems.

Comment 2 James Olin Oden 2005-02-04 21:30:23 UTC
I can't fathom what reason you would want to on purpose have the same 
symbolic link delivered by the same package where one package would 
never be installed without the other (you wouldn't install chkconfig 
without initscripts, right?).   But what I can fathom, and what is 
reality are generally different things, so could you please give a 
reason for this?

As far as their being functional problems, in this case there is not 
one, but if two packages delivered the same symbolic link and they 
happened to point to two different files, that IMHO is a file 
conflict.  Which is why we added to our distribution dependency 
checker to check for file conflicts and to not ignore symbolic links 
(directories where ignored).  

Actually, the reason we added this build time check was because 
anaconda is appearantly ignoring file conflicts when delivering 
files.  I could not figure out why anaconda would do that, but now 
that I know that RHEL 3 has several file conflicts (one in with vimrc,
this one, and another having to do with some python library rpms) I 
can see why they would need to ignore file conflicts.

I am not trying to be scathing, I am only trying to make you see why 
this file conflict a bad thing, and that is because it makes it 
impossible to use rpms file conflict capability if these rpms end up 
in a transaction (which I guess is what must have happened with 

For our part we can create some "dependency whiteout" in our checker 
to ignore these special cases, but it really does not give me warm 
fuzzies to do so. 

Comment 3 Bill Nottingham 2005-02-04 22:30:04 UTC
Yes, file conflicts are bad, but this isn't one; they're identical.

As for the reason for this; as said, it was 5+ years ago, and my
memory is failing in my old age. I'll attempt to dig it up.

Note You need to log in before you can comment on or make changes to this bug.