On Tue, 16 Feb 2016 21:42:18 -0700
Stephen John Smoogen <smooge(a)gmail.com> wrote:
========================
Apologies and So Forth
========================
First, I would like to apologize for the delay in getting this post
done. I really didn't realize the amount of energy the trip would take
from me and how fuzzy brained I was for a week afterwords. Second, I
would like to thank the Open Source and Standards (OSAS) group at Red
Hat for sponsoring me that week. I believe I got a lot of things done
and that we can work on getting Extra Packages for Enterprise Linux
(EPEL) moving forward in some direction. Third I would like to thank
everyone who took the time to talk to me at one of these places to
tell me about what they were able to do with EPEL and what they were
no longer able to use it for.
Thanks for talking to folks and writing this up!
...snip...
* The packaging guidelines for each EPEL version are not clear. This
is mainly due to the fact that they are usually based off of older
versions of Fedora (Fedora-6 for EPEL-5, Fedora-12 for EPEL-6, and
Fedora-18 for EPEL-7) that may conflict with each other or with how
things are being done in current EPEL.
I've always gone with: "Fedora guidelines apply except for these small
changes", but yeah, we could be better about those changes. Tibb's
recent macro works might reduce these, but I don't think we can ever
get to 0.
* EPEL does not have a regular release structure like Fedora and
RHEL
have. There isn't an EPEL-5.11 channel with an epel-updates-5.11
where updates are available. Because of various repository
limitations, this means that directories aren't able to keep
multiple old copies so downgrades when things do break aren't easy.
Yeah. I think we could include 2 versions of everything (at the cost of
2x of the mirror space and bandwith), but then you have things like
foo-1.0 has a major security bug and foo-1.1 came out to fix it, and
you trick someone into downgrading or installing the old one and
exploit them. ;(
* EPEL promises to keep things stable and only update for fixes, but
this is only done on a few packages where others get upgraded to and
fro. There does not seem to be much "steering" or "release
engineering" of what is in the trees.
Yeah, I think mostly this is due to the fact that there is not anyone
who works on EPEL full time. Everyone who does things does them in
their "spare" time, so having some kind of micro scrutiny isn't in the
cards. ;(
I think we could improve this with more feedback... when an
incompatible upgrade goes out, ask people to note it so we can talk to
the maintainer and ask them not to do that kind of thing.
* EPEL only covers part of Enterprise Linux (the Server product) but
a
lot of packages are for the Workstation but there is no way to see
when things replace/conflict with them. [People believe that we
build against the equivalent of CentOS-5/6/7 versus a subchannel.]
Yeah, not sure how to fix that without a second workstation branch. :(
* EPEL sometimes has weird breaks between releases. The git in
EPEL-5
is newer than what is in EL-6 in a way that was breaking
repositories when pushes were done from EL-5 systems. [People
believe there is a promise that such changes are tested against.]
Huh, first I have heard of that one..
* EPEL packages disappear. If there is no maintainer packages are
retired but if someone is re-building out the EL-5 hosts.. they need
that package to be available. [People believe there is a promise
that packages will be always available.]
Yeah. Again, continuing to ship an old vulnerable version of something
seems bad, but I wish we had a better way to communicate this. ;(
* From various people who were (or former) EPEL maintainers:
packages
in EPEL are the most complained about. If they can't update the
package in EPEL, they get complaints about it being too old and they
may end up having a newer version available for what they need to do
anyway. If they do update the version, they get complaints that they
broke someone because they needed some old version. Most of the
complaints usually are the worst kinds ( off-hand death threats (why
don't you die in a fire) etc etc).
Yeah, sad. It's the old Enterprise linux mantra: "I want everything to
be 100% stable, secure and never change, except for this one thing I
care about, that should be todays git checkout every day"
==============================
Things people wanted in EPEL
==============================
There were various things that people were wanting in EPEL that
weren't really breakages because they don't exist yet.
* Enable 'alternative' architectures. There were requests from people
about CentOS-i386 and CentOS-arm (for the Raspberry Pi2 in schools)
with no vision on how those would be enabled.
We talked about this in the last meeting. There's apparently 3-4 ways
we could do this, all of which require work. I hope we can get Dennis
to post to the list these options and try and decide which we want to
go with and who will step up to help work on it.
* Enable more packages with shorter lifetimes. One of the things
that
multiple sites were doing was rebuilding all of a Fedora release for
their internal mirrors to supplement all of the things that EPEL
didn't have in it. Why can't there be an EPEL-rawhide where all of
these packages are built but no 'promises'?
We could, but again someone would need to step up to work on it.
This would be a lot of work as Fedora has vastly more packages that you
might think. ;)
* Is it possible to have a branch management system where packages
get
updated regularly? Say either whenever Fedora moves to a new release
or Red Hat updates to the next branch (6.7->6.8, 7.2->7.3)
We could mass rebuild at every release... but that also brings up the
time after a rhel release but before a centos release. ;(
* Could packages in EPEL be tested in the CentOS continuous
integration infrastructure as part of the autokarma testing?
No idea, but it would be lovely if it could work.
I don't think anything above is new to people who have been
contributing to EPEL in the last ~10 years. A lot of the problems are
ones that were brought up in the beginning as we tried to square the
circle of differing use cases. However, I wanted to catalogue them
here and then make a promise that I will do my best to figure out ways
to solve them by FOSDEM 2017 in some form or another.
It sounds to me a lot of it is communication. Perhaps we could figure
out some way to more directly communicate with users.
kevin