EPEL + EUS (Extended Update Support) [aka zStream]

[BJ Dierkes]

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:

[1] http://bit.ly/NGWcK

---
derks

[Bryan J Smith]

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.


-- 
Bryan J Smith       Senior Consultant       Red Hat, Inc
Professional Consulting http://www.redhat.com/consulting
mailto:[e-mail]         [phone] (Mobile) 
mailto:[e-mail]  (Blackberry/Red Hat-External) 
-------------------------------------------------------- 
You already know Red Hat as the entity dedicated to 100%  
no-IP-strings-attached, community software development.   
But do you know where CIOs rate Red Hat versus other      
software and services firms for their own, direct needs,
year after year?     http://www.redhat.com/promo/vendor/

[Stephen John Smoogen]

On Tue, May 11, 2010 at 1:23 PM, BJ Dierkes
<wdierkes(a)5dollarwhitebox.org&gt; 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:
>
>  [1] http://bit.ly/NGWcK
>
>  ---
>  derks
>
>
>
>
>  _______________________________________________
>  epel-devel-list mailing list
>  epel-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/epel-devel-list
>  


-- 
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines

[Kevin Fenzi]

On Tue, 11 May 2010 14:23:29 -0500
BJ Dierkes <wdierkes(a)5dollarwhitebox.org&gt; 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

[BJ Dierkes]

On May 11, 2010, at 11:24 PM, Kevin Fenzi wrote:

>  On Tue, 11 May 2010 14:23:29 -0500
>  BJ Dierkes <wdierkes(a)5dollarwhitebox.org&gt; 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