What happens inside a transaction is rpm business, reassigning.

Yum and rpm differ in that yum performs a test transaction first, rpm does not. This has historically been a source of all sorts of more or less subtle issues, this particular behavior wrt config files being a new variant of the old theme.

Fixed now upstream in the sense that file actions are reset entirely to ensure they get recomputed on reruns:
http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=f311fb65eea4791fa15a00412384b96fdccbbf1c

Of course, at this point one can question the point of running test-transactions if what is tested is not what is executed but that's %pretrans' fault, not yum.

For the record, I'll also note that messing underneath rpm to the level that the java package is now doing is a bad idea and asking for trouble. ACK for fixing the inconsistency due to partial state being preserved, but this does NOT mean the kind of thing the java package is doing is somehow "supported".

Clearing needinfo, see comment #3.

Thank you!

When do you guess this change can reach live fedora/rhel-7 ?

RHEL-side of things depends on acks, nothing more.

On Fedora side rpm fixes primarily come via upstream releases rather than individual patch backports, but obviously exceptions are sometimes made.

Fixed in rpm-4.11.1-16.el7

Hi Panu!

is it possible to do an fedora rawhide build with this fix please?

Also regarding to your note - DO you have any idea for openjdk how to face this issue?

Hi Jiri,
could you please summarize how rpm is supposed to work? I have created SPEC samples with changes being performed on config(noreplace) during the %pretrans phase. I used rpm-4.11.1-16.el7. My observations are:

1. factory version of config doesn't differ between packages -> there is no config backup created and the config file is rewritten with the %pretrans modification

2. factory versions differ -> .rpmnew contains the factory version from the update, config file contains the %pretrans modification

3. I have customized the config for the old version -> situation same as for 2. and my customization is lost

So to summarize it, doing file changes inside %pretrans doesn't look like a good idea.

OK, after the conversation with Jiri I can summarize my observations:

A) scenario important for Java guys:

setup:
- pkg v1 has config(noreplace) /etc/pkg.conf
- pkg v2 has config(noreplace) /etc/pkg-v2.conf
  in %pretrans section there is "cp /etc/pkg.conf /etc/pkg-v2.conf" to ensure 
  that we can (re)use old configuration

rpm-4.11.1-15.el7:

rpm -Uvh pkg does detect that pre and post %pretrans version of /etc/pkg-v2.conf differs and creates .rpmnew file with the new version
  while
yum localupdate pkg doesn't and the old version is silently overwritten.


rpm-4.11.1-16.el7:

both rpm -U and yum localupdate works as expected - old version is preserved and new version stored in .rpmnew

B) scenario with same config file location, config file modified only during %pretrans

In this case both rpm versions overwrite the config file in %pretrans without preserving the original version. This is because rpm believes that the old and the new version is same and doesn't care.

It is probably up to the discussion whether the B) should be "fixed" or not.

(In reply to jiri vanek from comment #10)
> Hi Panu!
> 
> is it possible to do an fedora rawhide build with this fix please?

Looks like this was done on 2014-03-26:

rpm-4.11.2-3.fc21
http://koji.fedoraproject.org/koji/buildinfo?buildID=507005

* Wed Mar 26 2014 Panu Matilainen <pmatilai> - 4.11.2-3
 - dont eat newlines on parametrized macro invocations (#1045723)
 - fully reset file actions between rpmtsRun() calls (#1076552)
 - fix build and sign module initialization in python3 (#1064758)

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.