how to effect "Conflicts: %{name}-foo != %{version}-%{release}"

Panu Matilainen pmatilai at laiskiainen.org
Wed Feb 15 06:57:25 UTC 2012


On 02/01/2012 02:15 AM, Brian J. Murrell wrote:
> Let's say I am repackaging an RPM (called foo) supplied by my distro
> vendor which has the following packages:
>
> foo-ui
> foo-tools
>
> and my repackaging is to separate out foo-tools into foo-tools and
> foo-devel.  First I bump the Release: ever so minor by just tacking a
> ".01" onto the end of it so that my package will "upgrade" the vendor
> package but the next vendor package should upgrade mine (by which time,
> with any luck, they have incorporated my -devel packing patch).
>
> In my new foo-devel subpackage I put:
>
>    %package   devel
>    Summary:   devel for foo
>    Group:     ...
>
>    %description python
>    provides devel bits
>
> And add a %files for foo-devel and change the %files for foo-tools to
> remove the files I put into foo-devel.
>
> But I want to provide a smooth downgrade path to vendor's original
> package, so I want to have the vendor's foo-tools remove my foo-devel.
> The solution that came to mind immediately was to put a:
>
> Conflicts: %{name}-tools != %{version}-%{release}
>
> into my foo-devel package's specification.  That way, when any other
> version of foo-tools installs, it will conflict with my packages
> foo-devel and (I think/hope) remove it.

Conflicts are not typically automatically removed (obsoletes are), they 
need manual resolution.

>
> But of course "!=" is not a legal operator.
>
> How else can I achieve my goal though?  It goes without say that I
> cannot do anything with the vendor's release of the foo-* packages since
> that toothpaste is already out of the tube.

The != can be achieved with two conflicts:

Conflicts: %{name}-tools < %{version}-%{release}
Conflicts: %{name}-tools > %{version}-%{release}

	- Panu -


More information about the Rpm-list mailing list