Best stab at questions

[Stephen John Smoogen]

I am playing ketchup, and saw these questions.. here are my take on
them as EPEL Steering Committee head.

Also note that while I use RHEL, I am meaning it as a short hand for
Red Hat Enterprise Linux, CentOS, Scientific Linux, etal.

> 1) How do appliances fit into EPEL?

EPEL is meant to be a repository for extra packages that do not get
shipped in EL but meet the 'same' packaging criteria as most Red Hat
Enterprise Linux "Core" packages do. This means that using EPEL as a
repository when building should help make integration easier.

> 2) Is RPM a requirement for EPEL?

Yes, all packages in EPEL are stored in RPM format.

> 3) If we deploy to EPEL, do all of the packages we depend on need to be in EPEL as well?

No. You could use packages in your appliance outside of EPEL, but in
the case of 'conflicts' it could cause problems in integration or
updates. Areas where I see packages not being in EPEL would be:

 a) Other propietary packages.
 b) Reliance on packages that do not meet EPEL's packaging structure
(putting things in /opt. Requiring packages that are 'newer' than RHEL
"Core" packages etc.

> 3a) If so, who is responsible for getting those packages into EPEL?

EPEL is a community project. We grow stronger with help and weaker
without it. If your company would be better off by having someone
spend some time a week making a package get into 'upstream' then you
would be an excellent candidate to help.

> 4) How is Fedora/Community prepared to help getting business applications into EPEL?

Applications that are in EPEL need to meet Fedora's packaging
standards plus RHEL standards. That means the code needs to be FLOSS
and also not conflicting with items that RHEL ships intact.

Thus if your application needs libwidget-1.7.1 and it is not in RHEL,
and the code is GPL, BSD, MitX, Apache, and/or MPL (plus a long list
Tom can go over) it can get included in EPEL. Then everyone else who
needs libwidget can benefit and they can report/fix problems that may
affect it. And you do not need to keep a separate package around in
your code base with your own patches etc.

A bad fit would be trying to include something that falls outside of
Fedora/RHEL standards. Trying to get kmod-Win95 ( a GPL kernel module
that loads in the windows 95 kernel) would not be ok since its outside
of Fedora/RHEL standards being that it is a kernel driver . Another
bad one would be a closed source code.

> 4a) Are there FTEs devoted to getting business applications into EPEL?

That is a Red Hat business decision I can't answer to.

> 5) Do you need to go through Fedora to get to EPEL?

Yes and no.. You need to sign the Fedora CLA and make sure the package
meets Fedora packaging and licensing standards. There may also be some
'rough' spots where we work out how to get it into EPEL but not in
Fedora proper if needed, but we will be filling out and testing those
methods soon with some compat packages.

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