Red Hat Bugzilla – Bug 147184
symbolic links (e.g. /etc/rc0.d) with multiple providers
Last modified: 2014-03-16 22:52:15 EDT
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,
Version-Release number of selected component (if applicable):
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.
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.
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.
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.