FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Packaging

 
 
LinkBack Thread Tools
 
Old 03-12-2010, 04:38 PM
Kevin Fenzi
 
Default Thoughts for EPEL incompatible upgrades woes

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
 
Old 03-12-2010, 04:40 PM
Jon Ciesla
 
Default Thoughts for EPEL incompatible upgrades woes

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

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

-d. bowie

--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 03-12-2010, 09:38 PM
Patrice Dumas
 
Default Thoughts for EPEL incompatible upgrades woes

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

Thread Tools




All times are GMT. The time now is 07:43 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org