[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Proposal: dealing with non-upgradeable packages.





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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]