Release and update procedure for EPEL

[Michael Stahnke]

On 3/2/07, Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> On 02.03.2007 13:36, Dennis Gilmore wrote:
> > Once upon a time Thursday 01 March 2007, Karsten Wade wrote:
> >> On Thu, 2007-03-01 at 11:31 -0600, Michael Stahnke wrote:
> >>> Wasn't Red Hat introducing something along the lines of a LAMP stack
> >>> that rolls on top of RHEL?  LIke it would actually have PHP5/MySQL
> >>> 5(or maybe 4.1) on top of RHEL 4.  It was a separate subscription I
> >>> thought, but a valid idea.  The latest software for what is needed,
> >>> and stable known-good software for the rest.
> >> Yep, launched last September.  From the right-side column here:
> >> https://rhstack.108.redhat.com
> >> ... is this list of apps and versions:
> >> HTTPD Apache 2.0.59
> >> JBoss AS 4.0.5
> >> MySQL 5.0.30
> >> PHP 5.1.6
> >> Perl 5.8.8
> >> PostgreSQL 8.1.8
> >> Red Hat Enterprise Linux 4 Update 4
> >> I suppose that makes those applications and versions not eligible to be
> >> packages in EPEL?  Is eligibility decided by applications or specific
> >> versions or both?  Or some other combination?
> > EPEL packages are not to replace packages in RHEL  so of those  we could maybe
> > include JBoss.
>
> +1 (including the maybe)
>
> >  though things get murky when it comes to Red Hat add on's
>
I guess I assumed we were not aiming to replace RHEL base packages.
As for the other channels of software, we probably need to visit each
one.  Does CentOS or Scientific currently repackage the other channels
that RH normally charges subscription for?  Excuse my ignorance, we
are strictly a RHEL shop.

For example, Directory Server, Application Server, Developer Suite
Channel, etc are all add-on channels that have a lot of great packages
but are not part of the core RHEL base.  Maybe it's a good topic for
this weekend's meeting?




> Exactly...
>
> Not sure, maybe the compromise needs to be something like this:
> ---
> EPEL Packages must not replace or conflict(¹) with Packages from it's
> base (e.g. RHEL) or directly related Add-On-Packages for it, that got
> released in the same timeframe as the RHEL-Release.
> ---
>
> CU
> thl
>
> (¹) -- conflict in the real life meaning of conflict, not the
> "Conflict:" usage in RPM (that's another discussion for later)
>
> _______________________________________________
> Epel-devel-list mailing list
> Epel-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list
>