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

[Stephen John Smoogen]

On Fri, Aug 8, 2008 at 8:50 PM, Michael Stahnke <mastahnke at gmail.com> wrote:
> Could we add this to the next steering committee meeting?  Here are the issues:
>

I am running a 102 fever but can't sleep so I hope this is lucid. The
next scheduled meeting is the 18th at some time UTC my brain is not
parsing.

> 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 would prefer to see it in EPEL in some form. The issue is how we
structure it and keep it working. [Well Joe needs perl-foo-baz-1.1 and
Bill needs perl-foo-baz-1.8.. ]


> 2.  Even competing with layered products seems bad.  If we would like
> RHX to have the same packages as in EPEL but be able to buy support
> for them, shouldn't RH do the same?  That way the software is
> available to those who would like to preview it, use it with CentOS,
> Scientific, etc.  I realize this contradictory to what EPEL started
> with, but our goal should be software to everybody, at least that's
> what I think.
>

I agree but I think we are going to need to change to meet this... how
we do this will be where we need to talk with the community and get
some ideas.

> 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 think that if its in Fedora, and does not conflict/update it can go
into EPEL so OpenJDK, FreeIPA, FedoraDS, Spacewalk, could meet that
criteria.

> 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.
>

This gets harder.. what is the distribution license on the firmware
packages? Even if its meant to make some hardware work.. I know this
will cause all kinds of "why can't we hack it.. its not free and cant
be in Fedora stuff." And I think that will fall under the if its not
in fedora its not in EPEL.

> I am sure there are more questions and conflicts, and I don't want to
> stomp on Red Hat, but I would like to make EPEL as usable and complete
> as possible.

> PS I won't be the EPEL meeting Monday.

I had it marked for the 18th. Is Monday not working for people?

>
> stahnma
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list
>



-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"