2:05 p.m.
At FLOCK this year, I did a short workshop on what was labeled EPEL.Next.
At that we went over a bit of what EPEL has done in the past, what its
current challenges are, and what could be its future. Toshio Kuratomi was
great in capturing what was said at the meeting and
EPEL
* Extra packages for enterprise linux
* Lots of name recognition now
* Formed as rhel5 was being released
people needed more packages. at the time there were a ton of addon repos.
None of the m were compatible with each other necessarily.
All the other repos, dag, freshrpms, etc overrode the base os in some
places.
Decided for EPEL, overriding RHEL was something we wouldn't do.
Started with RHEL3,4 and soon after release we had 5.
RHEL was supported 5-7years and we figured we could support EPEL packages
for the same length of time.
Early controversy - repotags (shortened name that can be in the packages.
[graph of Fedora machines measured by unique ips that hit mirrormanager vs
EPEL machines]
[graph shows steady growth in EPEL. Larger initial Fedora machines that
rose and then plateaued]
[graph shows a noticable dip every weekend. Can also see the dip in Fedora
numbers for the Incident.]
[graph is probably conservative in numbers as many enterprises
Second graph:
[Graph shows combined growth same as last graph.]
[Graph shows EPEL5 that has risen but plateaued about the time EPEL6 came
out.]
[graph shows that EPEL6 has been growing and has surpassed the EPEL5
plateau.]
Where are we now:
We support 3 arches.
RHEL4: 1258 srpms. EOL
RHEL5: 3651 srpms
RHEL6: 5449 srpms
RHEL7: 3100 srpms and growing fastest
For CENTOS7: the epel repofile will be shipped directly with centos for the
first time.
Current Problems:
* 10+ year support for RHEL now. Hard for EPEL packagers to commit to
doing the same.
* We have requests for both newer and older conflicting packages.
- Currently policy is not to have unpleasant surprises regarding
compatibility.
- puppet2.x vs puppet3.x
* Some people need major changes to build new software
* Some people need no changes in order to keep existing software running
* Developer burnout: People come in and after a few years, they are burnt
out because they can't upgrade the things that they want due to the
compatibility policies.
Where are we going?
Pain Points:
* Inability to yum downgrade because only include one old package in the
updates tree
* Harder for EPEL than Fedora because EPEL users have more need to
rollback if an incompatibility creeps in and because EPEL users may
schedule their releases
* Not every part of package repo is suitable for inclusion in anaconda
because we may not have dep closure in the subset of the repo.
* Which RHEL point release can also make a difference because the base
RHEL sometimes upgrades incompatibly and we don't keep a separate build for
both point releases.
* Can take a long time to push packages through bodhi. Can take 7 days to
push a CVE through bodhi. (global EPEL and Fedora problem)
* Not all maintainers interpret "Don't break compatibility" in the same
way.
* Many guidelines are verbal, not formal.
* Some maintainers are mainly Fedora maintainers and don't know what people
are using it for in EPEL. They respond to requests to install or update a
package out of a willingness to help but don't know what users need.
* No guideline enforcement.
* Takes a while for new EPEL releases to be brought out once a new RHEL
release is made (because CentOS hasn't released yet).
* Traditionally, we wait because contributors may not have RHEL
entitilements so they need to have CentOS to test.
* Need entitlements for contributors to run RHEL (Easiest: Use RHEL,
SciLinux, Fermi Linux).
* Packages get added to one of the RH base repositories and then we have to
pull them from the EPEL repositories.
* Some people have extra layered products from RH and do not want us to
conflict with those. Other people do not have the layered products and
therefore want to be able to get those packages from EPEL.
* Overlap between EPEL and CentOS Extras.
Ideas to deal with Pain
* Get RHEL licenses for contributors. There is a process but it takes a
long while because of the tax problems for giving it to people. Current
procedure is that we get requests, we give the names to a person inside of
RH and then they eventually get back to us with licenses.
* Let's create EPIC: separate repo. 3 year lifespan instead of 10 year,
rhel life cycle.
* Debian Volatile repository and also Debian Backports. These repos
contain newer versions of packages, even for Debian Stable. Good for
packages which change all the time.
* Debian also has protection mechanism that says no major or no major.minor
version updates in apt (their yum equivalent).
* Red Hat already releases different lifecycle repositories (layered
products). Why not replicate what they do.
* What about implementing EPEL as a set of projects like Fedora Playground?
* Would change the guarantees and expectations of EPEL *quite* a bit.
* Maybe as the way to implement EPIC rather than EPEL.
* Policy change that allows for regular major changes in EPEL.
* Can't update at any times.
* Can make incompatible changes on the next point release of RHEL->CentOS.
* Example: When RHEL7.1 comes out we have a 30 day window to get packages
updated and new packages in that make incompatible changes.
* Archive 7.0. The toplevel 7 tree is a symlink to whatever point
release is latest.
* Formalize the governance of EPEL.
* Written policies of some sort for decision making
* Elections?
* Problems to solve:
* Don't want to just listen to the people who are loudest
* Don't want to just listen to the people who have been around the
longest
* Do we want automated testing of EPEL? yes. get it working on whatever
subset you can and we'll go on from there.
* Move to CentOS as build system? Gives us additional arches.
* Could we do an ISV program like quaid does?
--
Stephen J Smoogen.