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.
Test case details please.
[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.
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.
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).
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.
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
Sorry, yes, file conflicts - they appear to be treated differently when installed in the same transaction, as opposed to disparate transactions.
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.
Nice buck passing. Too bad rpm-python isn't involved here at all.
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.
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 :)
Or rather, the packages don't break, multiarch installs will... (unless a lot of packages are further split into separate libs + binary parts)
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.
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.
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.
This is still unfixed.
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
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...
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
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.