Bug 1076552 - rpm -U behaves differently then yum update
Summary: rpm -U behaves differently then yum update
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: rpm
Version: 7.0
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: ---
Assignee: Panu Matilainen
QA Contact: Karel Srot
URL:
Whiteboard:
Depends On:
Blocks: 1038092 1243947
TreeView+ depends on / blocked
 
Reported: 2014-03-14 14:23 UTC by jiri vanek
Modified: 2015-07-16 16:17 UTC (History)
11 users (show)

Fixed In Version: rpm-4.11.1-16.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 13:29:35 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description jiri vanek 2014-03-14 14:23:05 UTC
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 11:00:37 UTC
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 11:04:50 UTC
Clearing needinfo, see comment #3.

Comment 5 jiri vanek 2014-03-21 11:31:03 UTC
Thank you!

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

Comment 6 Panu Matilainen 2014-03-21 11:57:34 UTC
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 11:29:06 UTC
Fixed in rpm-4.11.1-16.el7

Comment 10 jiri vanek 2014-03-26 12:14:30 UTC
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 13:28:47 UTC
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 14:33:03 UTC
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 21:44:35 UTC
(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 13:29:35 UTC
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.