Proposal: dealing with non-upgradeable packages.
Stephen John Smoogen
smooge at gmail.com
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.
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.
--
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