Hello all,
I wanted to ping the list for your thoughts on EUS/zStream [1] as it relates to EPEL. I've asked in an IRC meeting before but the general consensus was EPEL wasn't going to bother with EUS. What I wanted to see is, who [if anyone else] is concerned about making EPEL available for EUS. There is no way obviously to honor the EUS patching requirements of only backporting security fixes, however making EPEL available for users of EUS might be something to consider.
The issue is, my company is evaluating the use of EUS however we also have the requirement of offering custom packages and EPEL. But subscribing EPEL (built against RHEL 5.5) to an EUS box running RHEL 5.3 [for example] has the potential to break things (ehhem libevent). Currently my options are to a) rebuild EPEL packages against each EUS point release on my own, or b) maintained point-in-time repos that simply provide all the packages when that point release was last updated and then no longer update that EPEL channel (not a good scenario).
Just wondering if this is a dilemma for anyone else and what the plan might be.
References:
--- derks
On Tue, 2010-05-11 at 14:23 -0500, BJ Dierkes wrote:
Hello all, I wanted to ping the list for your thoughts on EUS/zStream [1] as it relates to EPEL. I've asked in an IRC meeting before but the general consensus was EPEL wasn't going to bother with EUS.
Not being in the IRC, is the current EPEL system (via Koji and other facilities) capable of building for EUS v. just the lead EL update? That would be my first, technical question.
The issue is, my company is evaluating the use of EUS however we also have the requirement of offering custom packages and EPEL. But subscribing EPEL (built against RHEL 5.5) to an EUS box running RHEL 5.3 [for example] has the potential to break things (ehhem libevent). Currently my options are to a) rebuild EPEL packages against each EUS point release on my own, or b) maintained point-in-time repos that simply provide all the packages when that point release was last updated and then no longer update that EPEL channel (not a good scenario).
My client has both EUS and taps EPEL, allowed by official policy.
We maintain internal EPEL repositories on our RHN Satellite Servers. EPEL is cloned as a child channel under each EUS base channel anyway, so we already have "b" by default, without doing anything else. If we want "a", it's just a matter of a rebuild. We haven't needed to yet.
Yes, there is the potential to run into a newer EPEL package that would break in on a previous, EUS release system. But again, we haven't run into it yet. At the same time, EUS releases are only maintained for around a year. EUS is designed for transition, to minimize breakage during transition.
So if you have EUS, you might already be doing "b" if you maintain your own repositories (such as we do in Satellite). So it really comes to do doing "a" only when needed. Not sure if that's really something that falls to EPEL. After all, EUS is really only offered for maximizing integration/regression issues during a transition.
There's no guarantee that an update in EPEL won't cause such anyway, even for the leading update, from a previous EPEL package release. It's up to Fedora Project maintainers to create backports, and not just rebase an update.
At least that is my view.
On Tue, May 11, 2010 at 1:23 PM, BJ Dierkes wdierkes@5dollarwhitebox.org wrote:
Hello all,
I wanted to ping the list for your thoughts on EUS/zStream [1] as it relates to EPEL. I've asked in an IRC meeting before but the general consensus was EPEL wasn't going to bother with EUS. What I wanted to see is, who [if anyone else] is concerned about making EPEL available for EUS. There is no way obviously to honor the EUS patching requirements of only backporting security fixes, however making EPEL available for users of EUS might be something to consider.
Ok here are the issues:
1) It takes a lot of disk space to support zStream releases. Not just in the FTP mirrors but also in the build system as each zStream needs to be mirrored in the buildsystem.
2) The naming structure of EPEL would require some work because you would need to make sure that if you build a package built against EL-5.3 got upgraded when the user updates to EL-5.5. This would require work in the build system, packaging scheme, bugzilla, etc. While some of the work is trivial, enough is not and there aren't a lot of cycles (dgilmore is our main person to do most of the grunt work and his cycles are quite limited).
The issue is, my company is evaluating the use of EUS however we also have the requirement of offering custom packages and EPEL. But subscribing EPEL (built against RHEL 5.5) to an EUS box running RHEL 5.3 [for example] has the potential to break things (ehhem libevent). Currently my options are to a) rebuild EPEL packages against each EUS point release on my own, or b) maintained point-in-time repos that simply provide all the packages when that point release was last updated and then no longer update that EPEL channel (not a good scenario).
Just wondering if this is a dilemma for anyone else and what the plan might be.
References:
derks
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Tue, 11 May 2010 14:23:29 -0500 BJ Dierkes wdierkes@5dollarwhitebox.org wrote:
Hello all,
...snip...
Just wondering if this is a dilemma for anyone else and what the plan might be.
I think this might be possible, but it would take a lot of work. Currently we don't have different tags or repos for each of the zstreams.
This would take at least:
- Setup new tags for 5.0, 5.1, 5.2, 5.x, etc so they inherit right. - Mirror repos for all the streams on the buildsys - Setup mirrors so each stream is a seperate area.
It would be a lot of work. ;( Perhaps if there was enough interest and people were willing to work on it we could consider it.
kevin
On May 11, 2010, at 11:24 PM, Kevin Fenzi wrote:
On Tue, 11 May 2010 14:23:29 -0500 BJ Dierkes wdierkes@5dollarwhitebox.org wrote:
Hello all,
...snip...
Just wondering if this is a dilemma for anyone else and what the plan might be.
I think this might be possible, but it would take a lot of work. Currently we don't have different tags or repos for each of the zstreams.
This would take at least:
- Setup new tags for 5.0, 5.1, 5.2, 5.x, etc so they inherit right.
- Mirror repos for all the streams on the buildsys
- Setup mirrors so each stream is a seperate area.
It would be a lot of work. ;( Perhaps if there was enough interest and people were willing to work on it we could consider it.
Thanks Kevin, and others. Based on the amount of work, and seemingly low demand (atleast at this time)... I won't hold my breath for now. ;) I appreciate the feedback though.
--- derks
epel-devel@lists.fedoraproject.org
-
BJ Dierkes -
Bryan J Smith -
Kevin Fenzi -
Stephen John Smoogen