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?

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...

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com