We have been struggling with a issue in 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.
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. ;(
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).
- 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
- 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.