Bug 190209

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.