[Fedora-packaging] Thoughts for EPEL incompatible upgrades woes

[Jon Ciesla]

Kevin Fenzi wrote:
> 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
>   
> ------------------------------------------------------------------------
>
> --
> packaging mailing list
> packaging at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/packaging
Funny, the 3rd option is what I'm trying to do with Drupal.

https://bugzilla.redhat.com/show_bug.cgi?id=569833

-J

-- 
in your fear, seek only peace
in your fear, seek only love

-d. bowie