On Apr 9, 2008, at 3:58 PM, Ralf S. Engelschall wrote:

> I've a bunch of "alternative" packages which in the RPM 4 era were of
> the style:
>
> | Name:         fooNN
> | [...]
> | Provides:     foo = %{version}-%{release}
> | Conflicts:    foo
>
> For instance, package "openvpn" is the primary packaging of OpenVPN
> 2.0.x while package "openvpn21" is the packaging of the current beta
> version of OpenVPN 2.1. The package "openvpn21" is mutually exlusive
> to "openvpn", only one of the two should be installed as both contains
> usually exactly the _same_ filesets, etc.
>
> In RPM 4 the construct was to use "Provides: foo =
> %{version}-%{release}" so that packages which depend on "foo" are
> satisfied also with an installed "fooNN" and the "Conflicts: foo" was
> used to explicitly say that "fooNN" conflicts with "foo" (which was  
> both
> a hint to RPM and to the XML/RDF indexer we are using).
>
> Now with RPM 5 I recognized that when a package both provides "foo"  
> and
> conflicts with "foo" in effectively seems to conflict with _ITSELF_  
> and
> hence cannot be installed at all.
>
> Questions for me are:
>
> 1. Is this the intended behaviour for RPM 5
>    and a known incompatability to RPM 4?
>

Requested change (I believe I know the cause). Previously,
rpm used NEVR to test for same package, the test is now
stricter where "identical" is tested with SHA1 header digest.

Requested by Dmitri Levin July 2006 if memory serves. I've
forgotten the exact details, can find the discusssion if necessary.

But certainly self-conflicting packages server no useful purpose.
I'm sure a few logic tweaks will sort the issue.

> 2. Should one now just not use both "Provides" and "Conflicts" at
>    the same time and also indexers now have to figure out the conflict
>    theirself?
>
> I at least found the special exception that a package cannot conflict
> with itself a reasonable exception and hence was surprised that RPM 5
> seem to behave differently. Before I start hacking I wanted to check
> with you what the intentions are...
>

Show me a reproducer and I'll suggest what I would do to fix. AGain,
self-conflicting packages server no purpose whatsoever, certainly
not intended by any means.

73 de Jeff