Bug 190209 - Raise file conflicts always, not just on additional transactions
Raise file conflicts always, not just on additional transactions
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Panu Matilainen
Fedora Extras Quality Assurance
bzcl34nup
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-28 16:00 EDT by Bill Nottingham
Modified: 2014-03-16 22:59 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-30 04:02:28 EST
Type: ---
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 Bill Nottingham 2006-04-28 16:00:11 EDT
If you have conflicting multiarch packages:

A.i386
A.x86_64

A RPM install transaction consisting of both packages will succeed.

A RPM install transaction of A.x86_64, followed by a RPM install transaction of
A.i386, will raise a conflict on the second transaction.

This behavior should be consistent, raising the conflict in all cases.
Comment 1 Jeff Johnson 2006-04-29 09:28:40 EDT
Test case details please.
Comment 2 Bill Nottingham 2006-05-01 14:54:22 EDT
[root@mercury ~]# rpm -ivh xmlsec1-devel-1.2.9-4.2.*
Preparing...                ########################################### [100%]
   1:xmlsec1-devel          ########################################### [ 50%]
   2:xmlsec1-devel          ########################################### [100%]
[root@mercury ~]# rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n"
xmlsec1-devel
xmlsec1-devel-1.2.9-4.2.x86_64
xmlsec1-devel-1.2.9-4.2.i386
[root@mercury ~]# rpm -e xmlsec1-devel.i386
[root@mercury ~]# rpm -ivh xmlsec1-devel-1.2.9-4.2.i386.rpm
Preparing...                ########################################### [100%]
        file /usr/bin/xmlsec1-config from install of xmlsec1-devel-1.2.9-4.2
conflicts with file from package xmlsec1-devel-1.2.9-4.2

xmlsec1-devel i386 & x86_64 can be pulled from rawhide.
Comment 3 Jeff Johnson 2006-05-04 18:01:53 EDT
There is code in lib/depends.c rpmtsAddInstallElement() that tries to prevent
identical NEVR from being installed in the same transaction, so I question your reproducer.

Here's what I see (of course I'm not on x86_64, and not using rpm-4.4.2, but the
code is identical between 4.4.2 and 4.4.7 by inspection}

# rpm -ivh xmlsec1-devel-1.2.9-4.2.{x86_64,i386}.rpm
warning: package xmlsec1-devel = 1.2.9-4.2 was already added, skipping xmlsec1-devel < 1.2.9-4.2
error: error reading from file xmlsec1-devel-1.2.9-4.2.i386.rpm

So I question whether you actually achieved 2 xmlsec1-devel packages in the same transaction ...

I also know of no easy way (by intent) to specify an inter-arch conflict. Sure you can do
    Conflicts: /usr/lib64/path/to/somewhere
but that's a path, not an inter-arch, conflict.
Comment 4 Bill Nottingham 2006-05-04 18:13:25 EDT
I suspect running on x86_64 with "%_transaction_color     3" may have something
to do with it; I assure you that both arches are installed afterwards (see the
rpm -q query directly after; they're both in the database).
Comment 5 Jeff Johnson 2006-05-04 19:20:35 EDT
OK, prolly me then. I've forgotten what I had to do to install x86_64 on i386 to diagnose problems. ;-)

FWIW, there are tests on identical N that probably explain the mis-behavior, and there is a change
last summer to narrowly limit identical to matching Hdrid, not loosey-goosey NEVR, that may
be relevant.
Comment 6 Jeff Johnson 2006-05-04 19:45:14 EDT
Ah yes, %_transaction_color was the problem. Getting old ... ;-)

Hmmm, you mean "file conflicts" (but reproduced finally):

[root@wellfleet S]# rpm -ivh --fileconflicts xmlsec1-devel-1.2.9-4.2.i386.rpm 
Preparing...                ########################################### [100%]
   1:xmlsec1-devel          ########################################### [100%]
[root@wellfleet S]# rpm -ivh --fileconflicts xmlsec1-devel-1.2.9-4.2.x86_64.rpm  
Preparing...                ########################################### [100%]
        file /usr/bin/xmlsec1-config from install of xmlsec1-devel-1.2.9-4.2 conflicts with file from 
package xmlsec1-devel-1.2.9-4.2

Comment 7 Bill Nottingham 2006-05-05 10:55:10 EDT
Sorry, yes, file conflicts - they appear to be treated differently when
installed in the same transaction, as opposed to disparate transactions.
Comment 8 Jeff Johnson 2006-06-23 08:16:11 EDT
There is no way to return the file conflict error through the tuple returned by ts.check() in the python 
bindings from the natural place to implement intra-transaction file conflict, lib/rpmal.c.

The rpm-python maintainer has been notified of the problem -- repeatedly.

DEFERRED until the script kiddies get their act together.
Comment 9 Bill Nottingham 2006-06-28 23:30:30 EDT
Nice buck passing. Too bad rpm-python isn't involved here at all.
Comment 10 Jeff Johnson 2006-07-02 07:53:12 EDT
Implementing a functionality that will cause errors that cannot be returned to all applications, not just 
rpm, that use rpmlib, makes no sense to me.

If DEFERRED doesn't help change the inability the report the error to existing python bindings, then
lets try WONTFIX, shall we? It's silly to introduce a new behavior error retrun that cannot be reported.
Comment 11 Panu Matilainen 2007-11-13 02:14:49 EST
Do you actually want conflicts on all files, or just non-elf? Of course it'll
never be fully consistent unless all file conflicts are treated as such,
multiarch or not, but it'd mean breaking helluva lot of packages :)
Comment 12 Panu Matilainen 2007-11-13 02:17:11 EST
Or rather, the packages don't break, multiarch installs will... (unless a lot of
packages are further split into separate libs + binary parts)
Comment 13 Bill Nottingham 2007-11-13 09:46:23 EST
Right now, the behavior is confusing, as you may or may not get conflicts
depending on how you upgrade. Making it consistent would be good. If nothing
else, it would provide motivation to fix packaging.
Comment 14 Panu Matilainen 2007-11-13 10:30:35 EST
The behavior is not only confusing, it's also inherently broken wrt verify and
erasure. Not to mention the installation ordering related issues with scriptlets
attempting to execute color-shadowed binaries and...

In other words, I'm all for it.
Comment 15 Bug Zapper 2008-04-03 13:13:49 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 16 Tomas Mraz 2008-04-03 14:18:38 EDT
This is still unfixed.
Comment 17 Bug Zapper 2008-05-13 22:09:15 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 18 Panu Matilainen 2008-07-14 07:46:00 EDT
Moving back to rawhide.

The new rpm in rawhide has a partial fix for this: conflicts are always raised
for non-colored files. The rest would be taken care off by just turning off the
coloring completely to stop the multilib elf "sharing" of binaries, but I doubt
we'd be ready for that in F10...
Comment 19 Bug Zapper 2008-11-25 20:49:19 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 20 Panu Matilainen 2009-01-30 04:02:28 EST
Hmm actually this is fixed in F10 (since last July): the conflict behavior is consistent, which is what the original request was - colored files are allowed to overlap whether in same transaction or not, and for everything else conflicts are always raised.

Eliminating the "sharing" of colored files is another issue.

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