[Fedora-packaging] Thoughts for EPEL incompatible upgrades woes

[Kevin Fenzi]

Greetings. 

We have been struggling with a issue in EPEL
( https://fedoraproject.org/wiki/EPEL ) for quite some time, and I
thought I would ask the folks here for thoughts on what the best way
forward might be. 

Background: EPEL provides add on packages for RHEL/CentOS/etc. 
It uses Fedora Packaging Guidelines and procedures. 
It never provides a package when RHEL provides it already in it's
RHEL-AP package set. EPEL strives to provide an update stream that
never provides incompatible upgrades. Ie, if something was installed
and working it should keep working after an update. 

https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies

Problem: For the majority of packages, there is no problem and we are
fine. However, for some small subset of our packages, upstreams provide
incompatible updates. This leaves us in a hard place. ;( 

Examples: 

mediawiki - changes database schema and other things on upgrade,
requiring manual scripts and backups/restores. 

rdiff-backup - newer versions can't talk to older versions, so if epel
gets upgraded, you must upgrade all your rdiff-backup instances in
order to keep backing them up. 

moin - newer versions have script or database changes that make
unattended upgrades impossible. 

nagios - Newer versions have incomptible config, requiring manual
tweaking in order to keep running after upgrade. 

(I'm sure there are others). 

Possible solutions: 

- Currently we do nothing. Those packages sit there with their old old
  versions and get only very limited updates. Anyone installing them
  now asks why they are so old or out of date. We just wait for RHEL6
  and hope. 

- Provide a 'slipstream' repo. We either keep providing the old version
  in the main repo, or drop it if there are security issues. We provide
  a newer incomptible version in the slipstream repo. This repo has big
  warnings that updates in it could be incompatible and need manual
  attention, and is off by default. (ie, they have to enable it). This
  means another branch in cvs, more rel-eng time to manage, etc. 

- Provide packages and reviews for the new version. ie, 'mediawiki18-' 
  This would be a newer version that is incomptible with the base one
  provided. Could we use Conflicts here? Or would we need to require
  that any "forward compatibilty" package here does not conflict with
  the base package? This means we have a small number of new reviews,
  new packages. It also means that people who don't know to look for it
  will not see it until someone tells them to install that version
  instead of the base version. It also means we accumulate these over
  time and have to EOL them somehow. 

- Your more clever solution here. ;) 

There's no good answer here, but mainly I wanted to see what folks
thought about the packaging the new version as a seperate package.
Kinda like fedora compat packages, except the newer version. 

Thoughts? Comments? 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/packaging/attachments/20100312/9ac54e54/attachment.bin