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:
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 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.
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.