RFC: Rethinking EPEL at FUDcon Lawrence 2013

Jan Pazdziora jpazdziora at redhat.com
Thu Nov 22 09:56:33 UTC 2012


On Thu, Nov 22, 2012 at 10:15:30AM +0100, Matthias Runge wrote:
>
> For some packages, keeping them up to date and 100% compatible to a
> version released, when that package was added to EPEL is simply
> impossible for volunteers.
> As (bad) example, php in RHEL 6 is php-5.3.3, latest stable release is
> php-5.4.8; I'm taking my hat off for everybody back-porting fixes for
> every error fixed in between those releases.

[...]

> To come to my proposal:
> We should have something like channels, for simplicity analogous to EPEL
> releases (i.e. RHEL releases). When a newer channel is opened (i.e. a
> newer RHEL minor version is released), EPEL package maintainers should
> be allowed to do upgrades.

The schedules RHEL operates on are not necessarily aligned with the
schedules of the individual components in EPEL. Having more channels
/ streams of EPEL could lead to unnecessary increase of work for
maintainers who'd suddenly face much more complex rel-eng setup.

I believe there are fundamentaly conflicting interests of different
groups of people WRT the stability of the package versions vs. access
to new technology. Often even a single person may have different needs
and expectations from one package (I really depend on *this on* to be
stable) vs. another one (upstream has these new cool features that I'd
like).

For your php example above, wouldn't the solution be to name one
package php53, another php54, and let people happy with 5.3 stay with
php53 while people who want to move on would have to knowingly replace
the packages? The packages would install to the same paths so they
would conflict and you'd need to pick one.

In Spacewalk project, we've seen our users were recently hit by
a rebase of one EPEL component that broke long-time users of the
original version. We ended up having to package the original
version under different name in Spacewalk (to avoid upgrade to
EPEL's version by accident). Maybe if this approach became the
preferred one in EPEL, to provide both versions, we could put the
package to EPEL directly.

-- 
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat




More information about the epel-devel-list mailing list