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
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@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
On Fri, Mar 12, 2010 at 10:38:11AM -0700, Kevin Fenzi wrote:
- 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.
In my opinion this is the best solution, and sill in my opinion there should not be conflicts. Maybe alternaties could be used.
-- Pat
packaging@lists.fedoraproject.org
-
Jon Ciesla -
Kevin Fenzi -
Patrice Dumas