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@xxxxxxxxxxxxxxxxxxxxxxx > 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 -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
