Some EPEL thoughts (was Re: perl-Net-Telnet both in EPEL and RHEL)

[David Juran]

I think most of my opinions have already been expressed, but since I
started this thread I feel I should weigh in as well...

On Fri, 2008-08-08 at 21:50 -0500, Michael Stahnke wrote:
> Could we add this to the next steering committee meeting?  Here are the issues:
> 
> 1.  "Layered" products, such as cluster server, ship some support
> packages like perl modules, etc.  Should those be allowed in EPEL?
> They are not part of core RHEL.  IMHO, as much software as possible
> should be available for everybody.  At my place of employment, if I
> need a package and it's not in EPEL, I then have to build/maintain my
> own, which is what EPEL hopes to stop.  I could see the EPEL committee
> denying some 'core' packages of each layered channel, (such as RHDS
> core packages, cluster server core packages for RHEL 4, etc).

I basically agree with Thorsten.  I would however like to stress that if
a package from the layered products is taken into CentOs, the NEVR
should never override the version shipped in the RHEL layered product
since it will make life hard for customers of the RHEL layered products
if they get the EPEL version in by mistake and then contact Red Hat
support. For EPEL maintainers without access to RHEL and RHN, they can
have a look at ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ for a
view of what the layered product contains. Unfortunately a bit of an
awkward approach but still...

> 3.  What about products such as Free IPA vs IPA, Fedora DS vs RHDS,
> Spacewalk vs Satellite etc?  If there is a fully open offering, can we
> put it in EPEL and not officially be 'conflicting' with the RH channel
> for it?

I see no fundamental reason why these should be left out, but from a
technical side, care must be taken so that packages from these channels
not override base RHEL packages. For a case study, have a look at the
hoops that had to be jumped through in order to wrangle DS8 into RHEL4
[1]. IMHO, if we do this, we should take the CentOS approach of just
rebuilding the Red Hat SRPM:s. That would however create the need for
"compat-style" packages in EPEL that are not needed in Fedora proper.
Not sure if this would be a problem.

> 4. Firmware packages that are on the supplemental EL discs.  To me,
> this is just to make some hardware work, shouldn't that be easily
> available?  As an enterprise customer, it'd be a lot easier to have it
> in EPEL (which I am going to use anyway) than to have to
> download/import the supplemental disc.

Again I see no fundamental reason to exclude them (provided that the
licensing is OK for Fedora) but are they really needed in EPEL? I
believe all RHEL customers have access to the supplemental channel and
can get the packages from RHN just as easily as from EPEL. If EPEL would
choose to include them, I would urge that care be taken not to override
the RHEL NEVR.


[1] -
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/RHDirServ/x86_64/SRPMS/
-- 
David Juran
Sr. Consultant
Red Hat
+358-504-146348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20080811/0102dd16/attachment.sig>