Re: RFC: Rethinking EPEL at FUDcon Lawrence 2013

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