I sent a ping a while back on putting in a weight of 2000 for EPEL-6 and the general consensus was that it did not matter to them what we did. [More or less.] So I would say that when we update the epel-release next time to put it in the epel.repo. [And make sure we announce it for partners.]
On Sat, 18 Sep 2010 11:40:28 -0600 Stephen John Smoogen smooge@gmail.com wrote:
I sent a ping a while back on putting in a weight of 2000 for EPEL-6 and the general consensus was that it did not matter to them what we did. [More or less.] So I would say that when we update the epel-release next time to put it in the epel.repo. [And make sure we announce it for partners.]
And if we do that, we should be able to clone RHEL Workstation packages (the ones not in RHEL Server) and put them EPEL without causing issues for RHEL Workstation users...
Shouldn't we?
Paul.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/18/2010 11:10 AM, Paul Howarth wrote:
On Sat, 18 Sep 2010 11:40:28 -0600 Stephen John Smoogen smooge@gmail.com wrote:
I sent a ping a while back on putting in a weight of 2000 for EPEL-6 and the general consensus was that it did not matter to them what we did. [More or less.] So I would say that when we update the epel-release next time to put it in the epel.repo. [And make sure we announce it for partners.]
And if we do that, we should be able to clone RHEL Workstation packages (the ones not in RHEL Server) and put them EPEL without causing issues for RHEL Workstation users...
Shouldn't we?
I'm of the opinion that we should still not do this, except for extreme situations. EPEL was not meant to be an end-run around RHEL packages or RHEL pricing, and while we could technically do it and have less chance of hurting people's systems, I don't think EPEL is the place for that. There is plenty of room for a slightly more removed repository from EPEL where one could provide updated versions of packages.
- -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
On 19/09/10 19:29, Jesse Keating wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/18/2010 11:10 AM, Paul Howarth wrote:
On Sat, 18 Sep 2010 11:40:28 -0600 Stephen John Smoogensmooge@gmail.com wrote:
I sent a ping a while back on putting in a weight of 2000 for EPEL-6 and the general consensus was that it did not matter to them what we did. [More or less.] So I would say that when we update the epel-release next time to put it in the epel.repo. [And make sure we announce it for partners.]
And if we do that, we should be able to clone RHEL Workstation packages (the ones not in RHEL Server) and put them EPEL without causing issues for RHEL Workstation users...
Shouldn't we?
I'm of the opinion that we should still not do this, except for extreme situations. EPEL was not meant to be an end-run around RHEL packages or RHEL pricing, and while we could technically do it and have less chance of hurting people's systems, I don't think EPEL is the place for that. There is plenty of room for a slightly more removed repository from EPEL where one could provide updated versions of packages.
Well let's suppose that when RHEL-6 comes out, there's no add-on repository to provide Workstation packages for Server customers. Are you suggesting that a server product like bugzilla, which has at least one dependency on a Workstation-only package (https://bugzilla.redhat.com/show_bug.cgi?id=626218) should be moved to a "slightly more removed repository"? And where might that be?
Paul.
On 19 September 2010 20:29, Jesse Keating jkeating@redhat.com wrote:
On 09/18/2010 11:10 AM, Paul Howarth wrote:
And if we do that, we should be able to clone RHEL Workstation packages (the ones not in RHEL Server) and put them EPEL without causing issues for RHEL Workstation users...
Shouldn't we?
I'm of the opinion that we should still not do this, except for extreme situations. EPEL was not meant to be an end-run around RHEL packages or RHEL pricing, and while we could technically do it and have less chance of hurting people's systems, I don't think EPEL is the place for that. There is plenty of room for a slightly more removed repository from EPEL where one could provide updated versions of packages.
Except that's not what we're talking about doing (the Fedora discussion about recent versions of packages is separate). *If* there is no "productivity" channel for Server then we're not talking about bypassing the pricing scheme, we're talking about something that people just plain can't get through Red Hat. Things like perl packages which are in Workstation (b2 refresh) as dependencies for GUI tools, but are used by server type services, eg RT, and which RHEL Server doesn't provide.
The only time your argument hold up in this case is if there is a paid for channel that provides the additional packages. At which point we'll need to decide which channels we're targeting. What makes things worse is that as RHEL becomes a more complex product, with more bolt-ons and options, trying to create EPEL becomes more complex: Exactly which combinations of channels and architectures are we aiming to provide packages for?
With the perl tree this has become a nightmare, it was tough getting things like RT in before when some packages were pinned to old versions, but now you're suggesting that some we couldn't even have, simply because a GUI happened to use it in RHEL Workstation?
However, at this point I am just going to say, let's wait until details of how RHEL6 is going to be structured are public, so we can at least make an informed decision and not do things that are going to make Rel-Eng-EPEL's life difficult. If this means that there's going to be a lag of a few weeks before EPEL is completely ready, post GA, then that's life. If anyone wants to help get stuff ready, post GA because they want to deploy ASAP well they can always help with the EPEL effort, we are after all simply volunteers.
Mark
At which point we'll need to decide which channels we're targeting. What makes things worse is that as RHEL becomes a more complex product, with more bolt-ons and options, trying to create EPEL becomes more complex: Exactly which combinations of channels and architectures are we aiming to provide packages for?
Maybe the question could be worded slightly differently : which channels is CentOS targeting ? This is the only freely available tree to build against and this is what the EPEL mock configs are pointing at.
Regards, Xavier
epel-devel@lists.fedoraproject.org
-
Jesse Keating -
Mark Chappell -
Paul Howarth -
Stephen John Smoogen -
Xavier Bachelot