Proposal: dealing with non-upgradeable packages.

[Stephen John Smoogen]

On Mon, Jul 13, 2009 at 1:43 PM, Stephen John Smoogen<smooge at gmail.com> 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.
>
>  Package should contain a README that states
>   a) Software is deprecated and no longer supported by EPEL or
>   upstream.
>   b) They can get the source code for software from: BLAH.
>
>  Questions: How do we branch this? Create a new 'toplevel' package
>  called moin16 or soemthing else? Create a new 'hospice' repo where
>  stuff goes to die but people who still require it can get it?
>
>
> 2) Newer packages are named with appropriate tags also. Instead of being
>   called moin-1.9, it would go in channel as moin19-1.9. This breaks
>   with upstream but fits better with the audience we are facing. Work
> with fesco on what should be long term fix.
>


Workflow for a non-upgradeable package.

Packager finds that p0wnme will not upgrade cleanly between 1.7.9 and
1.8.1 which is the current maintained one. Packager alerts appropriate
people (fill in here) and the work flow goes as follows:

Current package: p0wnme-1.7.9
New packages are created:
p0wnme17-1.7.9 :
  replaces p0wnme < 1.8
  conflicts p0wnme18
  is a new CVS top package
p0wnme18-1.8.1 :
  is identical to Fedora p0wnme-1.8.1 series and if 1.9 is incompatible
  upgrade (it will most likely be) will be a new top level package at
  some point in the future.

The only other solution I can come up with is somehow creating branches
in RPM/yum..




-- 
Stephen J Smoogen.

Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning