We have an feature, multiple jdks installed in parallel. It means, that each new jdk installs to new directory. One can then swithc those in alternatives. However, it lead to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1038092
We solved it by lua script in pretrans, which is working well in rpm -i or rpm - U. The script is executed also during yum update (see http://pkgs.fedoraproject.org/cgit/java-1.7.0-openjdk.git/commit/?id=3916dd1ddefdb1d4a83fd26bb4cc61215345305f with debug info)
however, after you update no rpmsave or rpmnew exists!
Do you mind to explain the difference between you and rpm whicha re causing it?
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:
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.
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
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?
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:
- 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 -Uvh pkg does detect that pre and post %pretrans version of /etc/pkg-v2.conf differs and creates .rpmnew file with the new version
yum localupdate pkg doesn't and the old version is silently overwritten.
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:
* Wed Mar 26 2014 Panu Matilainen <email@example.com> - 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.