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.

1. 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?
2. 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.

Continue with same repository, alternate package names for new versions

Pros

• Similar to existing process

Cons

• Same stagnation problem with older packages as split repositorie

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)