Bug 147184

Summary: symbolic links (e.g. /etc/rc0.d) with multiple providers
Product: Red Hat Enterprise Linux 3 Reporter: Joe Keller <joseph.keller>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED WONTFIX QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-02-04 20:27:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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 
links:
  /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):
7.42.2-2

How reproducible:
Always

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

Actual Results:  [root@wrx root]# rpm -qf /etc/rc0.d
chkconfig-1.3.11-0.3
initscripts-7.42.2-2


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 
anaconda).  

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.