EPEL/Rethinking

DRAFT

Background

For a while now there have been off and on discussions about the state of packages and their versions in in EPEL.

Here is a list of recent discussions, please add to it if you think it needs to be longer.

• https://www.redhat.com/archives/epel-devel-list/2012-October/msg00015.html
• https://www.redhat.com/archives/epel-devel-list/2012-October/msg00032.html
• https://www.redhat.com/archives/epel-devel-list/2012-October/msg00043.html
• https://www.redhat.com/archives/epel-devel-list/2012-November/msg00051.html

Stephen John Smoogen started off RFC: Rethinking EPEL at FUDcon Lawrence 2013 with the following call to action:

OK from the various problems with various packages and the needs of packaging groups for a faster place for development and users for a more stable and knowing release cycle.. I would like to open the floor to what we can do to make EPEL more useful to both groups as best as possible with the goal that the proposals are finalized by FUDcon Lawrence and work on them completed within 6 months. Formalize what EPEL does and how it does it. Who gets to decide about updates How do we update major items (regularly after a RHEL release? after a Fedora release?) How do we say "we can't support this architecture/release" anymore? Make sure it is documented what the Fedora Build System can do for us and what it can't. Repotags (yes/no) Multiple channels for devel, testing, stable, old (yes/no)? Building for PPC/etc architectures when we don't have systems anymore?

Ideas

Here is the summary of the ideas that have been discussed... additions and expansion upon is encouraged. If you aren't confident about a change you are making, please bring it up on the epel-devel list. The plan is to discuss these further at FUDcon 2012 in Lawrence, Kansas.

Monetize EPEL long term support

Have a company pull a Red Hat and start offering long term support and backporting for EPEL software.

Pros

• Takes the difficulty off the volunteers

Cons

• Not likely?

Splitting into two repositories, stable and rolling

Pros

• Helps both sets of users (stable vs current)

Cons

• Will likely lead to the stable repo becoming overly stagnant and users not knowing they aren't secure.
• Requires lots of infrastructure work: bodhi, mash, git, etc.
• Two repos could diverge enough to where you couldn't cross share packages.

Continue with same repository, alternate package names for new versions

Pros

• Similar to existing process
• Existing package users keep using package without disruption.
• Users could choose to install/upgrade to new version on their timeframe.

Cons

• Same stagnation problem with older packages as split repository
• Work to parallel install/package things. High barrier to entry.

Allow invasive changes/upgrades around minor point releases

This would be a set of incompatible changes that we would land around a minor point release. Say 6.4 to 6.5.

Pros

• Allows a specific time to make big incompatible changes to our users.

Cons

• Users would be forced to update on our timeframe, not theirs.
• Timing could be difficult: RHEL isn't pre-announced, community rebuilds might lag.

Implement a yum plugin that handles breakable updates

Have a plugin that processes information about breakable updates from repodata. An update marked breakable will be added to the exclude list to prevent systems from breaking. For informational purposes a notice should be displayed and/or logged. If a breakable update is required because older 'stable' version is insecure and there will be no update, hard fail the yum process with an error requiring manual intervention.

Pros

• Allows for single repository going forward with both stable and updated packages
• Could allow for older version to receive updates even if a newer release is available

Cons

• Requires errata processing, similar to security, allowing for definition of criteria
• Requires a plugin be installed and present on all consuming systems
• Requires someone to write the errata (likely the package maintainer)
• Initial race condition where someone might get the new plugin and a breakable update in the same update (how does yum deal with this kind of scenario? I know I've seen it update before updating other packages)

Decide what _exactly_ EPEL will promise to try and not overlap with

Our choices:

• Base RHEL and Optional

• Base RHEL and Optional and HA and LB

• Those channels that are enabled in the epel-build repo in the buildsystem.

• Any package in Any RHEL channel

• Any package in Any RHEL channel that has src.rpms on ftp.redhat.com