When the package is being install or upgraded and for some reason (e.g. install failed part way through or something like that) the correct config file is already there (with correct permissions, MD5sum and time stamp), rpm should not rename it into .rpmorig (or create a new config as .rpmnew), it should just keep the existsing config (or overwrite it - obviously, it does not matter).
AFAICT, the "problem" is that you wish an rpm install to have separate apply and commit stages, you're unhappy with the muddle left when an install is only partially completed. In the works, deferred till then.
No, it's a separate problem. There are different reasons why the correct config file would already be there. May be you've upgraded the config file without upgrading the RPM. May be something else happened (for example, my RPM database was corrupted recently and I had to reinstall lots of packages to correct it). But it does not matter _why_ the config file is there. But if for some reason it is there, RPM should be smart and detect that rpmorig/rpmnew mechanism is not needed.
No it's not a seperate problem, as you are expecting graceful behavior under conditions of partial installs ("install failed part way through"), and that can't be done without a rigorous apply/commit methodology implemented in rpm which is in the works. Meanwhile, wrto %config handling, rpm is very, very smart about choosing a file disposition for %config files. In fact, there is no possibility of changing anything in the existing algorithm IMHO.
It is a separate problem. It has little to do with partial installs. Fixing partial install _will not_ completely eliminate this problem. Yes, I agree that %config handling in RPM is pretty good. But I believe that it still can be improved. Namely, when RPM sees that the configuration file that it is going to install _is already there_, it should not create an .rpmnew/.rpmorig version of it.
And I think you will find that the feature uou are requesting is already implemented if you do 1) prepare package with a non-zero length file marked %config(noreplace) 2) build and install that package 3) change the content of the file in the package slightly, bump the version, build and upgrade to new package. 4) Verify that no .rpmnew file is created during upgrade. Now repeat the same operation, but edit the %config(noreplace) file before upgrading, and verify that a .rpmnew file is created to preserve local user mods in situ. There's already a similar mechanism wrto .rpmorig. I do not believe the current %config handling can be improved at all. <shrug>
Yes, RPM would work fine in your scenarious, but they do not cover all the possible cases. Here are couple of ways to get RPM to do the wrong thing. --- 1) Create an RPM package with a %config (or %config(noreplace) ) file. 2) Manually install the config file from that RPM without toching the RPM itself. 3) Install the package created in (1). --- 1) Create an RPM package with a %config (or %config(noreplace) ) file. 2) Install it. 3) Create an updated package with an updated %config (or %config(noreplace) ) file. 4) Manually install the new config file in place. 5) Upgrade to newer package --- In both scenarious RPM with create a config file and a .rpmorig/.rpmsave/.rpmnew file _identical to that config file_ which is _completely unnecessary_. Instead, RPM should detect that the identical config file is already there and not create any .rpm*. These scenarious are quite realistic - the first one will happen, for example, if the RPM database gets corrupted and the second one will happen, for example, if you want to try using a new config with an old version of the software.
I need more precise, reproducible scenarios in order to even contemplate a change to %config handling. I need the following 1) the package that was installed 2) the package that will be installed 3) An exact description of what changed, and when, including file modes and mtimes. 4) a statement of desired behavior in order to even understand your request. Your scenarios do not provide information like ownership that may very well trigger the behavior that you find undesireable.
OK, I'll create a few test RPMs (with and without noreplace for each of the 2 scenareos) and I will upload them.
Thanks.
Created attachment 11700 [details] Test spec for scenario 1, see %description for more information.
Created attachment 11702 [details] Test spec file for scenario 1 with noreplace, see %description for more information.
I would imagine that these two spec files would be sufficient to see the problem, but I can create the test cases for scenario 2 as well, if necessary. Please let me know if you need them.
So, have I convinced you that there is still a place for improvement in %config handling?
OK, I'm convinced that there's room for improvement. Thanks for supplying detailed test cases. There are still legacy issues with users expecting the traditional rpm behavior. For example, if I were to implement the 2 changes you wish, consider what happens when a user erases the test1/test2 packages, the file contents will be removed, where, with the traditional implementation, the user will be left with *.rpmorig/*.rpmnew files that can be renamed. Leaving the *.rpmorig et al files also prevents directories owned by packages from being removed as well. Yes these are pathological objections, but the issue is pretty miniscule as well :-) Let me cogitate a bit, as the underlying problem is that the %config handling in rpm is far too mysterious and unpredictable already, better diagnostic messages supplying the reasons for choosing a certain file disposition need to be displayed with -vv. I'll try to get the 2 cases above worked in when I attempt better diagnostics.
This is still present in 7.2 and Skipjack beta.
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still running Red Hat Linux, you are strongly advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux or comparable. Some information on which option may be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/. Red Hat apologizes that these issues have not been resolved yet. We do want to make sure that no important bugs slip through the cracks. Please check if this issue is still present in a current Fedora Core release. If so, please change the product and version to match, and check the box indicating that the requested information has been provided. Note that any bug still open against Red Hat Linux on will be closed as 'CANTFIX' on September 30, 2006. Thanks again for your help.
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still running Red Hat Linux, you are strongly advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux or comparable. Some information on which option may be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/. Closing as CANTFIX.
Still present in RHEL 4.4, rpm-4.3.3-18_nonptl
Still in Fedora-devel.
See bug 128622 for patch which handles also this case.
Tomas' patch from bug 128622 c#11 upstreamed and also in next rawhide push (rpm-4.4.2.1-5.fc8)