From Fedora Project Wiki
(Created page with "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, ...")
 
(add more cases and info)
 
(2 intermediate revisions by one other user not shown)
Line 6: Line 6:
Here is a list of recent discussions, please add to it if you think it needs to be longer.
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/msg00015.html
https://www.redhat.com/archives/epel-devel-list/2012-October/msg00032.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-October/msg00043.html
https://www.redhat.com/archives/epel-devel-list/2012-November/msg00051.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:
Stephen John Smoogen started off [https://www.redhat.com/archives/epel-devel-list/2012-November/msg00051.html RFC: Rethinking EPEL at FUDcon Lawrence 2013] with the following call to action:
 
{| style="margin-left: 2em;"
|-
| style="border-width: 0; background-color: #efefef" |


OK from the various problems with various packages and the needs of
OK from the various problems with various packages and the needs of
Line 20: Line 24:
Lawrence and work on them completed within 6 months.
Lawrence and work on them completed within 6 months.


1) Formalize what EPEL does and how it does it.
# Formalize what EPEL does and how it does it.
- Who gets to decide about updates
#* Who gets to decide about updates
- How do we update major items (regularly after a RHEL release? after
#* How do we update major items (regularly after a RHEL release? after a Fedora release?)
a Fedora release?)
#* How do we say "we can't support this architecture/release" anymore?
- 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.
2) Make sure it is documented what the Fedora Build System can do for
#* Repotags (yes/no)
us and what it can't.
#* Multiple channels for devel, testing, stable, old (yes/no)?
- Repotags (yes/no)
#* Building for PPC/etc architectures when we don't have systems anymore?
- Multiple channels for devel, testing, stable, old (yes/no)?
|}
- Building for PPC/etc architectures when we don't have systems anymore?


= Ideas =
= Ideas =
Line 50: Line 53:
=== Cons ===
=== Cons ===
* Will likely lead to the stable repo becoming overly stagnant and users not knowing they aren't secure.
* 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 ==
== Continue with same repository, alternate package names for new versions ==
=== Pros ===
=== Pros ===
* Similar to existing process
* 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 ===
=== Cons ===
* Same stagnation problem with older packages as split repositorie
* 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==
== 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.
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.


Line 69: Line 91:
* Requires someone to write the errata (likely the package maintainer)
* 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)
* 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

Latest revision as of 22:49, 9 January 2013

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.

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.
  • 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