Two possibilities exist in order to face the problem in a correct way- in
rpm 4 e rpm 5 - , imho - i use it both:

1 - The two(or more) package go in conflicts in the files that compose them
:

pac1
--------------
Version : 1.0
Release: 1
Provides: pac =  %{version} -%{release}
Obsolets : pac

pac2
--------------
Version : 1.0
Release: 1
Provides:   pac =  %{version} -%{release}
Obsolets : pac

Result : or pac1 or pac2 is installed if you install pac1 or pac2. It is not
possible install pac1 and pac2 at the same time. The "pac" depency are
satisfied.



2 - The two (or more) packages conflicts in "logical sense" sense - so it is
possible to install  both but i don't want it.

pac1
------------
Version : 1.0
Release: 1
Provides: pac =  %{version} -%{release}
Obsolets : pac
Conflicts : pac2 ..... pacN

pac2
------------
Version : 1.0
Release: 1
Provides: pac =  %{version} -%{release}
Obsolets : pac
Conflicts : pac1,pac3 ..... pacN

The result is the same as in the first case.

Which is more in RPM 4.4.2-37.el5, just an example of rpm 4,  also it isn't
possibile, and I AGREED with this, to have a package that
conflicts with itself

Provides  : foo = %{version}-%{release}
Conflicts : foo

Also this reference could be useful, besides that something is based on some
rpm patch not upstream, imho:
http://en.opensuse.org/Upgrade_Dependencies


What do you think ?

Regards



On Wed, Apr 9, 2008 at 10:10 PM, Jeff Johnson <n3npq@mac.com> wrote:

>
> 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
>
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> Developer Communication List                        rpm-devel@rpm5.org
>