Bug 1076552 - rpm -U behaves differently then yum update
rpm -U behaves differently then yum update
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: rpm (Show other bugs)
7.0
Unspecified Unspecified
urgent Severity urgent
: rc
: ---
Assigned To: Panu Matilainen
Karel Srot
:
Depends On:
Blocks: 1038092 1243947
  Show dependency treegraph
 
Reported: 2014-03-14 10:23 EDT by jiri vanek
Modified: 2015-07-16 12:17 EDT (History)
11 users (show)

See Also:
Fixed In Version: rpm-4.11.1-16.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-13 09:29:35 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description jiri vanek 2014-03-14 10:23:05 EDT
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?
Comment 3 Panu Matilainen 2014-03-21 07:00:37 EDT
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".
Comment 4 Panu Matilainen 2014-03-21 07:04:50 EDT
Clearing needinfo, see comment #3.
Comment 5 jiri vanek 2014-03-21 07:31:03 EDT
Thank you!

When do you guess this change can reach live fedora/rhel-7 ?
Comment 6 Panu Matilainen 2014-03-21 07:57:34 EDT
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.
Comment 8 Panu Matilainen 2014-03-24 07:29:06 EDT
Fixed in rpm-4.11.1-16.el7
Comment 10 jiri vanek 2014-03-26 08:14:30 EDT
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?
Comment 11 Karel Srot 2014-03-27 09:28:47 EDT
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.
Comment 12 Karel Srot 2014-03-27 10:33:03 EDT
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.
Comment 16 Richard Fearn 2014-04-04 17:44:35 EDT
(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@redhat.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)
Comment 17 Ludek Smid 2014-06-13 09:29:35 EDT
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.

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