RFC: Rethinking EPEL at FUDcon Lawrence 2013

[Greg Swift]

I've been sitting on this too long... so just wanted to get it sent.  My
apologies about the flow.

On Fri, Nov 23, 2012 at 3:27 AM, Matthias Runge <mrunge at matthias-runge.de>wrote:

> On 11/23/2012 09:47 AM, Tomáš Smetana wrote:
> > And does every package have to be present in all the channels? I can
> imagine
> > a package having a different maintainer in each channel or not to be
> present
> > in some at all: if maintaining more versions at once or backporting
> patches
> > is beyond the maintainers possibilities, he may decide to only
> re-package the
> > new upstream stuff in "unstable" or just backport critical patches to the
> > "old" channel.
> >
> > Yes, I understand this may shift the complications to the users who will
> have
> > to invent more complicated yum configurations to get the right packages
> from
> > the right channels.
> >
> > Regards,
> >
> In my opinion, it's not necessary to have each package in each
> repository. Yum will do it's magic and select that package with the
> highest version number. E.g if you choose just the base EPEL-6 branch,
> then you should get the latest version of your desired package from
> there. If you also enabled e.g. EPEL-6.1 and the package from there is
> newer, then yum will fetch it from there. If that package doesn't exist
> there, you'll get, what's in EPEL-6.
>
> So using newer versions which may include upgrades, you'll need to
> enable another repository.
> But to be clear, I just intend ONE version upgrade for a package for
> each new repo, so when you chose to enable that newer repo, you'll stick
> on that provided version.
>
>
TL;DR
  - stability is nice
  - longer RHEL lifecycle = less useful EPEL if there are no updates
  - shouldn't be expected to solve local admin software management issues
  -


So... I agree with a lot of the overall concerns about stability, however
realistic expectations should be set on volunteers.  I also think we'd want
to avoid deviating to far from RHEL's update cycle beyond is absolutely
necessary (i'm referring to the concept of dot release repositories).

As an administrator I know it has annoyed me for years that I can't
specifically get many apps from EPEL just because of the major version
update rule.  In my experience I've ended up repackaging the Fedora RPM
because EPEL was just too far behind.

So, first, be patient with me as I look at RHEL for a second.

* Red Hat's release cycle for RHEL is ~8m per dot release (roughly averaged)
* RHEL is now on a 13 year support cycle (
https://access.redhat.com/support/policy/updates/errata/)
* Updated always go into the same repository (Unless you subscribe to
Extended Update Support (EUS), but I believe that is a separate repository
anyway)

Based on the above, most people have come up with a way to handle
deployment of updates in their environment:

1: paying extra to red hat for EUS
2: running a local repository that they manage the releases through
(satellite or manual)
3: auto or manually updating the boxes on a schedule
4: updating haphazardly
5: other?

So, unless someone wants to turn EPEL into a paid service, #1 is out
(hey... thats an interesting concept...)

To me (and most people I know) running your own local repository as a
'stability' control is way more efficient for the administrator.

If you are doing 3 and 4 then I don't know that requesting the EPEL
volunteers to provide that level of stability is very reasonable.

I can however appreciate that there are two primary sets of users from what
I've read on these conversations:

1: Those that don't want updates that change api compatibility
2: Those who need the newer version for X reason

I'm personally inclined to lean toward the concept I was pushing in the
thread discussing multiple versions [1].  I'd imagine that a 'api stable'
repo and a 'rolling' repo would be less support effort than attempting to
manage >8 repositories per major release and the security updates that need
to be applied on older version.

That being said I could about see doing a point in time 'snapshot' using
hardlinks of the single repository whenever a dot release comes out.  But
then what about security updates?

I realize that whichever route we go, work is required, but I also assume
that as a given at this point of the conversation.

-greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20121204/ea193877/attachment.htm>