Proposal: dealing with non-upgradeable packages.

Stephen John Smoogen smooge at
Mon Jul 13 19:43:24 UTC 2009

1) Create a package with a name of the version inserted in %{name}. Have
   the package replace the current version.
    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
   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.

Stephen J Smoogen.

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

More information about the epel-devel-list mailing list