Bug 29470 - rpmnew/rpmorig shouldn't be used if the correct config is already there.
rpmnew/rpmorig shouldn't be used if the correct config is already there.
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Panu Matilainen
David Lawrence
: Reopened
Depends On: 128622
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-25 18:22 EST by Aleksey Nogin
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-09 09:36:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test spec for scenario 1, see %description for more information. (1.03 KB, text/plain)
2001-03-03 14:56 EST, Aleksey Nogin
no flags Details
Test spec file for scenario 1 with noreplace, see %description for more information. (1.04 KB, text/plain)
2001-03-03 15:01 EST, Aleksey Nogin
no flags Details

  None (edit)
Description Aleksey Nogin 2001-02-25 18:22:20 EST
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).
Comment 1 Jeff Johnson 2001-02-26 08:57:48 EST
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.
Comment 2 Aleksey Nogin 2001-02-26 10:59:11 EST
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.
Comment 3 Jeff Johnson 2001-02-26 11:41:30 EST
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.
Comment 4 Aleksey Nogin 2001-02-26 13:41:51 EST
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.
Comment 5 Jeff Johnson 2001-02-26 14:03:09 EST
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>
Comment 6 Aleksey Nogin 2001-02-26 14:44:21 EST
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.
Comment 7 Jeff Johnson 2001-02-26 15:09:47 EST
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.
Comment 8 Aleksey Nogin 2001-02-26 23:41:49 EST
OK, I'll create a few test RPMs (with and without noreplace for each of the 2
scenareos)  and I will upload them.
Comment 9 Jeff Johnson 2001-02-27 09:30:33 EST
Thanks.
Comment 10 Aleksey Nogin 2001-03-03 14:56:00 EST
Created attachment 11700 [details]
Test spec for scenario 1, see %description for more information.
Comment 11 Aleksey Nogin 2001-03-03 15:01:18 EST
Created attachment 11702 [details]
Test spec file for scenario 1 with noreplace, see %description for more information.
Comment 12 Aleksey Nogin 2001-03-03 15:03:18 EST
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.
Comment 13 Aleksey Nogin 2001-03-13 18:43:34 EST
So, have I convinced you that there is still a place for improvement in %config
handling?
Comment 14 Jeff Johnson 2001-03-21 10:25:47 EST
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.
Comment 15 Aleksey Nogin 2002-03-28 04:01:04 EST
This is still present in 7.2 and Skipjack beta.
Comment 16 Bill Nottingham 2006-08-07 15:58:32 EDT
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.
Comment 17 Bill Nottingham 2006-10-18 13:17:56 EDT
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.
Comment 18 Aleksey Nogin 2006-12-15 19:48:32 EST
Still present in RHEL 4.4, rpm-4.3.3-18_nonptl
Comment 19 Tomas Mraz 2007-02-13 09:48:35 EST
Still in Fedora-devel.
Comment 20 Tomas Mraz 2007-02-13 09:52:11 EST
See bug 128622 for patch which handles also this case.
Comment 21 Panu Matilainen 2007-08-09 09:36:52 EDT
Tomas' patch from bug 128622 c#11 upstreamed and also in next rawhide push
(rpm-4.4.2.1-5.fc8)

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