Proposal: dealing with non-upgradeable packages.

[BJ Dierkes]

On Jul 13, 2009, at 2:43 PM, Stephen John Smoogen wrote:

> 1) Create a package with a name of the version inserted in %{name}.  
> Have
>   the package replace the current version.
>  Example:
>    moin-1.6.5 -> moin16-1.6.5
>    nagios-1.6.3 -> nagios16-1.6.3
>
>  What would be nicer if there was a Provides: moin <= 1.7 but I don't
>  think that works.
>


Should be important to note that the replacement package [moin17,  
moin18, etc] needs to provide moin = %{version}.  That is, any package  
that currently 'Requires: moin' would lose its dependency unless  
moinXY provides 'moin'.  I generally do the following:

%define %base_ver X.Y
Name: packageXY
Version: X.Y
Release: z
...
Provides: package = %{version}-%{release}
Conflicts: package < %{version}, package > %{version}
Conflicts: packageXX, packageXZ


Where packageXX is the older package, and packageXZ is the newer  
package (if that makes sense).  So, if the current 'moin' package is  
'moin-1.7' then the next replacement package would be something like...

%define base_ver 1.8
Name: moin18
Version: 1.8
Release: 1
...
Provides: moin = %{version}-%{release}
Conflicts: moin < %{base_ver}, moin > %{base_ver}
Conflicts: moin16, moin17



Things to note... you can't make moin18 'Obsolete: moin' unless you  
want every box with moin installed to upgrade to moin18 on the next  
stable push....  which would defeat the purpose of creating the  
separate package (safe/controlled upgrade).

Additionally, you provide moin = same_base_ver, and conflict with  
anything newer/older than that base_ver.


Hopefully i didn't make any logic flaws there... I think you get the  
idea though.

---
derks