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