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).
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.
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?
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.
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.
stahnma
On 09.08.2008 04:50, Michael Stahnke wrote:
Could we add this to the next steering committee meeting? Here are the issues:
- "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. [...]
I tend to agree. Heck most EPEL contributors don't even know what's in those layer products and have no way to check that. But OTOH it might be nice if possible without to much hassle to add them to EPEL with a EVR that is lower than the one in the layered product.
- 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?
The old goal was not to include those. But I'd now say we should. It's open source software; if people want it for free they will simply go somewhere else if people they don't get from EPEL. If they want support they'll pay RH anyway. Most are used to that concept from RH<->CentOS already anyway.
- 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.
Hmm. If they are free enough for Fedora/EPEL then why are they not free enough for the stock RHEL media?
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.
+1
Cu knurd
On Fri, Aug 8, 2008 at 8:50 PM, Michael Stahnke mastahnke@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.
- "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.. ]
- 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.
- 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.
- 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@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Fri, 8 Aug 2008, Michael Stahnke wrote:
Could we add this to the next steering committee meeting? Here are the issues:
- "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).
Don't those already ship as part of CentOS? Maybe we should just send people to CentOS if they want them but don't want to pay for them?
- 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'm curious about the future of RHX as well. Many of the groups in RHX have made a comittment to Open Source but that doesn't mean getting some of those packages playing well with the Fedora/EPEL model will be easy.
- 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'd think absolutely it could be in if it is non-conflicting.
-Mike
- 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'm curious about the future of RHX as well. Many of the groups in RHX have made a comittment to Open Source but that doesn't mean getting some of those packages playing well with the Fedora/EPEL model will be easy.
I've strongly suggested RHX help ISVs get content into EPEL. I'm not sure what their plan is though.
With EPEL, any users benefit in having their software available in yum-installable ways, they get a free build system, and the software is available to more than just RHEL. Plus, they have a community available to help them get their packages reviewed and in shape, and can more closely track things that are going on in the distro.
Generally the ones that have the hardest times are ones that have done things like package their own versions of certain components, especially java apps where this is accepted practice (and this is a /bad/ practice and needs to change for all distributions). For the java folks, they should probably also join https://www.redhat.com/archives/fedora-devel-java-list so that they can talk among themselves to figure out packaging issues.
Definitely not a super-easy problem, but it's a good way to ensure we get good RPMs for them and the distribution channel has a lot of advantanges, "yum search" being a primary one. I think it's pretty easy to sell the advantages, we just have to get them interested in doing the work.
--Michael
On Mon, 2008-08-11 at 10:53 -0400, Michael DeHaan wrote:
I've strongly suggested RHX help ISVs get content into EPEL. I'm not sure what their plan is though.
... and ...
Generally the ones that have the hardest times are ones that have done things like package their own versions of certain components, especially java apps where this is accepted practice (and this is a /bad/ practice and needs to change for all distributions). For the java folks, they should probably also join https://www.redhat.com/archives/fedora-devel-java-list so that they can talk among themselves to figure out packaging issues.
+1
Getting software in to Fedora/EPEL is pretty core to RHX's plan. I'm working as a catalyst across RHX, Fedora the Project, and various open source ISVs to do just that. We are moving at the speed of that friction spot between open source project and corporate time.
It is basically exactly as you say. It is a great idea to get these ISVs in to Fedora/EPEL. Nearly every Java (web) application is challenged by having dozens to over a hundred JARs that they either pull in manually or from Maven. JPackage may be part of the solution?
Definitely the discussion place for work is fedora-devel-java-list (just as non-Java discussions are fedora-devel-list), while the ISVs have a SIG to coordinate their similar needs in fedora-isv-sig-list (https://fedoraproject.org/wiki/SIGs/ISV).
Anyone who wants to help, those are the places to watch.
BTW, at LinuxWorld, someone from Linagora (http://omb.org) said they are waiting on package reviews. I'm trying to get ISVs to help each other, but be aware there may be cool software you'd love to see in Fedora that is hung in review. Is there somewhere I should draw attention to that? (/me thinks of his blog, for one.)
- Karsten
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:
- "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...
- 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.
- 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/
epel-devel@lists.fedoraproject.org
-
David Juran -
Karsten Wade -
Michael DeHaan -
Michael Stahnke -
Mike McGrath -
Stephen John Smoogen -
Thorsten Leemhuis