At today's EPEL meeting we got a bit closer to a new policy. Had a few proposals and started tweaking both the wording and the criteria that have been presented.
The basic framework that our proposals seemed to have was:
EPEL6 will not conflict with os, optional and specific other RHEL channels. Currently those are lb and ha. Other channels may be added [based on this criteria]. Overlaps are allowed to resolve packages missing on specific arches according to <link>
The sticking point is what to put in for the criteria. Suggestions given at the meeting were a combination of the following:
* case by case basis * Does not conflict with os, optional, or other channels already enabled * Available to people who have a basic subscription
In coming up with these criteria, we were attempting to satisfy these identified needs and desirable qualities:
* Must be usable in the buildsystem * Would like to make it easy on contributors to build and run the packages they are creating. * Set expectations appropriately for users of EPEL for what they can rely on as being protected and what is not * Limit the conflicts that can occur with Red Hat channels in some manner * Limit confusion for users of EPEL as much as possible given the other constraints.
FAQs:
* Why not just stick with os or os and optional?
It seemed like the things in lb and ha were generally useful to a large number of people, are currently enabled in the buildsystem, and are available to everyone who has a RHEL basic subscription currently. Removing them would mean trying to get them packaged for EPEL and also that we'd conflict with more packages that RHEL users could be using currently.
* Why not prohibit overlaps with all channels?
Primary reason is that channels conflict with each other so we can't enable all of them in the buildsystem successfully. This also seems to run counter to our other desired criteria.
* What now?
We need to work on the criteria and decide what ones we're actually going to go with.
-Toshio
On Fri, Jun 8, 2012 at 10:35 AM, Toshio Kuratomi a.badger@gmail.com wrote:
The basic framework that our proposals seemed to have was:
EPEL6 will not conflict with os, optional and specific other RHEL channels. Currently those are lb and ha. Other channels may be added [based on this criteria]. Overlaps are allowed to resolve packages missing on specific arches according to <link>
The sticking point is what to put in for the criteria. Suggestions given at the meeting were a combination of the following:
- case by case basis
- Does not conflict with os, optional, or other channels already enabled
- Available to people who have a basic subscription
For me, I feel the no conflicts portion is a blocker as that's what allows us to use the packages in the buildsystem. I really like the basic subscription criteria because it seems to be a good cutoff point for what a contributor to EPEL can be reasonably expected to have access to in order to build packages and run the results but it's not a blocker like the first one. So the proposal I came up with at the meeting was roughly:
EPEL6 will not conflict with os, optional and specific other RHEL channels. Currently those are lb and ha. Other channels may be added if they're available to people who have a base subscription to RHEL and the new channels don't conflict with the packages from Red Hat that we are already promising not to overlap with. Overlaps are allowed to resolve packages missing on specific arches according to <link>.
Wording can be tweaked as we see fit.
-Toshio
On Fri, Jun 8, 2012 at 1:35 PM, Toshio Kuratomi a.badger@gmail.com wrote:
At today's EPEL meeting we got a bit closer to a new policy. Had a few proposals and started tweaking both the wording and the criteria that have been presented.
The basic framework that our proposals seemed to have was:
EPEL6 will not conflict with os, optional and specific other RHEL channels. Currently those are lb and ha. Other channels may be added [based on this criteria]. Overlaps are allowed to resolve packages missing on specific arches according to <link>
I'm a little confused on the lb and ha points here and in the FAQ. So here we are saying that EPEL6 won't include packages from those Add-Ons?
The sticking point is what to put in for the criteria. Suggestions given at the meeting were a combination of the following:
- case by case basis
- Does not conflict with os, optional, or other channels already enabled
- Available to people who have a basic subscription
In coming up with these criteria, we were attempting to satisfy these identified needs and desirable qualities:
- Must be usable in the buildsystem
- Would like to make it easy on contributors to build and run the packages
they are creating.
- Set expectations appropriately for users of EPEL for what they can rely on
as being protected and what is not
- Limit the conflicts that can occur with Red Hat channels in some manner
- Limit confusion for users of EPEL as much as possible given the other
constraints.
FAQs:
- Why not just stick with os or os and optional?
It seemed like the things in lb and ha were generally useful to a large number of people, are currently enabled in the buildsystem, and are available to everyone who has a RHEL basic subscription currently. Removing them would mean trying to get them packaged for EPEL and also that we'd conflict with more packages that RHEL users could be using currently.
Really confused by this. LB and HA are useful but they are not available to everyone who has a basic RHEL subscription currently. They are both Add-Ons requiring additional subscriptions for access to them. What does it mean that they are currently enabled in the buildsystem? If that means other packages built for EPEL can include dependencies on what is in these channels that seems very dangerous unless they are packaged in EPEL since not everyone has access to them now.
John
On Fri, Jun 08, 2012 at 02:14:40PM -0400, inode0 wrote:
On Fri, Jun 8, 2012 at 1:35 PM, Toshio Kuratomi a.badger@gmail.com wrote:
At today's EPEL meeting we got a bit closer to a new policy. Had a few proposals and started tweaking both the wording and the criteria that have been presented.
The basic framework that our proposals seemed to have was:
EPEL6 will not conflict with os, optional and specific other RHEL channels. Currently those are lb and ha. Other channels may be added [based on this criteria]. Overlaps are allowed to resolve packages missing on specific arches according to <link>
I'm a little confused on the lb and ha points here and in the FAQ. So here we are saying that EPEL6 won't include packages from those Add-Ons?
Yes. I'll reply more below.
- Why not just stick with os or os and optional?
It seemed like the things in lb and ha were generally useful to a large number of people, are currently enabled in the buildsystem, and are available to everyone who has a RHEL basic subscription currently. Removing them would mean trying to get them packaged for EPEL and also that we'd conflict with more packages that RHEL users could be using currently.
Really confused by this. LB and HA are useful but they are not available to everyone who has a basic RHEL subscription currently. They are both Add-Ons requiring additional subscriptions for access to them.
Alright. We're operating under mis-assumptions then. In the meeting it seemed like this list was all the things that you could get with a basic subscription:
But that could be wrong or I could have interpreted what the list was supposed to mean incorrectly.
What does it mean that they are currently enabled in the buildsystem? If that means other packages built for EPEL can include dependencies on what is in these channels that seems very dangerous unless they are packaged in EPEL since not everyone has access to them now.
Correct. And I agree that that seems dangerous if not everyone has access to them now. Can we figure this out?
-Toshio
On Fri, 2012-06-08 at 11:39 -0700, Toshio Kuratomi wrote:
On Fri, Jun 08, 2012 at 02:14:40PM -0400, inode0 wrote:
On Fri, Jun 8, 2012 at 1:35 PM, Toshio Kuratomi a.badger@gmail.com wrote:
At today's EPEL meeting we got a bit closer to a new policy. Had a few proposals and started tweaking both the wording and the criteria that have been presented.
The basic framework that our proposals seemed to have was:
EPEL6 will not conflict with os, optional and specific other RHEL channels. Currently those are lb and ha. Other channels may be added [based on this criteria]. Overlaps are allowed to resolve packages missing on specific arches according to <link>
I'm a little confused on the lb and ha points here and in the FAQ. So here we are saying that EPEL6 won't include packages from those Add-Ons?
Yes. I'll reply more below.
- Why not just stick with os or os and optional?
It seemed like the things in lb and ha were generally useful to a large number of people, are currently enabled in the buildsystem, and are available to everyone who has a RHEL basic subscription currently. Removing them would mean trying to get them packaged for EPEL and also that we'd conflict with more packages that RHEL users could be using currently.
Really confused by this. LB and HA are useful but they are not available to everyone who has a basic RHEL subscription currently. They are both Add-Ons requiring additional subscriptions for access to them.
Alright. We're operating under mis-assumptions then. In the meeting it seemed like this list was all the things that you could get with a basic subscription:
But that could be wrong or I could have interpreted what the list was supposed to mean incorrectly.
What does it mean that they are currently enabled in the buildsystem? If that means other packages built for EPEL can include dependencies on what is in these channels that seems very dangerous unless they are packaged in EPEL since not everyone has access to them now.
Correct. And I agree that that seems dangerous if not everyone has access to them now. Can we figure this out?
For packages that overlap outside of base+optional, could we just agree to allow SRPM rebuilds with the exception that the EPEL release numbers must always be less than the official RHEL release numbers?
i.e. if we have mypackage-1.0-8.el6 in the HA channel, we can opt to repackage it in EPEL if-and-only-if the release number is 7.9 or lower (making it mypackage-1.0-7.9.el6).
On Fri, Jun 08, 2012 at 02:52:25PM -0400, Stephen Gallagher wrote:
For packages that overlap outside of base+optional, could we just agree to allow SRPM rebuilds with the exception that the EPEL release numbers must always be less than the official RHEL release numbers?
i.e. if we have mypackage-1.0-8.el6 in the HA channel, we can opt to repackage it in EPEL if-and-only-if the release number is 7.9 or lower (making it mypackage-1.0-7.9.el6).
That could be part of a solution but it's not all of a solution because the packages we could get from the channels can conflict with each other (mypackage-1.0-8.el6 might be in os, for instance, and mypackage-1.1-2.el6 might be in CloudForms. Or myfoo-1.0-1.el6 is in ha and myfoo-2.0-1.el6 is in RHVT).
-Toshio
On Fri, Jun 8, 2012 at 2:39 PM, Toshio Kuratomi a.badger@gmail.com wrote:
On Fri, Jun 08, 2012 at 02:14:40PM -0400, inode0 wrote:
Really confused by this. LB and HA are useful but they are not available to everyone who has a basic RHEL subscription currently. They are both Add-Ons requiring additional subscriptions for access to them.
Alright. We're operating under mis-assumptions then. In the meeting it seemed like this list was all the things that you could get with a basic subscription:
But that could be wrong or I could have interpreted what the list was supposed to mean incorrectly.
HA, LB, and Resilient Storage are channels called Add-Ons that require additional subscriptions (I'm not sure about the virt channels there). Could we be looking here at what comes with some "developer" subscription of some sort maybe?
This has some hints about which Add-Ons require more than a basic subscription.
https://www.redhat.com/apps/store/add-ons/
John
Toshio Kuratomi wrote:
- Set expectations appropriately for users of EPEL for what they can rely on
as being protected and what is not
I appreciate the continued efforts, and I want to hammer this one home. Expectations are the continuing key. Conflicts will happen, things will change, and there will never be a way to completely mitigate those. But changes in the expectations should rarely happen.
I think it's the reason many things keep coming up over and over.
inode0 wrote:
HA, LB, and Resilient Storage are channels called Add-Ons that require additional subscriptions (I'm not sure about the virt channels there). Could we be looking here at what comes with some "developer" subscription of some sort maybe? This has some hints about which Add-Ons require more than a basic subscription. https://www.redhat.com/apps/store/add-ons/
I've sat on this a bit, but feel it's time to try "another direction." It's these continuing comments that keep me literally "scratching my head." I hope it makes more sense from this, "alternative perspective" ...
It's not just the fact that Advanced Server, AS editions and Advanced Platform bundles have always included these, as a full, integrated stack, and they were avoided in EPEL from Day 1.
It's not just the fact that most (virtually all?) "Enterprise Linux (EL) Rebuilds" have also built and shipped these, also offering a full stack.
It's the fact that some have the view that instead of choosing one (1) of these two (2) "well integrated" options: A. Red Hat base channel + relevant child channels, *OR* B. EL Rebuild that includes the relevant child channels
They think this is a good idea from a "well integrated" standpoint for building: C. Red Hat base channel + EPEL options for child channels instead of Red Hat ones that were never, previously in EPEL (because they are, and have always been, in both "A" and virtually always "B")
To me, "B" is an outstanding, community option that many "EL Rebuilds" strived for bit-for-bit compatibility, have done well, and there's no reason they shouldn't continue to do well.
And looking at "A", if the idea is to build on actual Red Hat, then the entire Red Hat stack should be used whenever possible, especially for the AS/AP lineage that has always been the case.
What I don't understand is why people want to look at "C" at all for purposes of build. It should either be to get the channels from Red Hat, or leverage an EL Rebuild in my view. To change this would be to introduce a lot of issues for both types of users.
And yes, that's without even looking at it from Red Hat's support standpoint. It just doesn't make sense to me for EPEL build or development reasons at all.
-- Bryan J Smith - Professional, Technical Annoyance
On 8 June 2012 12:14, inode0 inode0@gmail.com wrote:
Really confused by this. LB and HA are useful but they are not available to everyone who has a basic RHEL subscription currently.
Well they seem to be available to the people who thought they had a basic subscription. What channels do you see with a basic subscription?
On Fri, Jun 8, 2012 at 5:16 PM, Stephen John Smoogen smooge@gmail.com wrote:
On 8 June 2012 12:14, inode0 inode0@gmail.com wrote:
Really confused by this. LB and HA are useful but they are not available to everyone who has a basic RHEL subscription currently.
Well they seem to be available to the people who thought they had a basic subscription. What channels do you see with a basic subscription?
None on this list of Add-On subscriptions.
http://www.redhat.com/products/enterprise-linux-add-ons/
I'd have to double check what you actually do get because it often includes lots of odd-ball channels.
John
On 8 June 2012 15:50, inode0 inode0@gmail.com wrote:
On Fri, Jun 8, 2012 at 5:16 PM, Stephen John Smoogen smooge@gmail.com wrote:
On 8 June 2012 12:14, inode0 inode0@gmail.com wrote:
Really confused by this. LB and HA are useful but they are not available to everyone who has a basic RHEL subscription currently.
Well they seem to be available to the people who thought they had a basic subscription. What channels do you see with a basic subscription?
None on this list of Add-On subscriptions.
http://www.redhat.com/products/enterprise-linux-add-ons/
I'd have to double check what you actually do get because it often includes lots of odd-ball channels.
Oh cool. That gives us the matrix of what is available with Red hat Server. Thanks inode0
We are building against Red Hat Enterprise Linux Server which comes with the following add-ons
High Availability Resilient Storage Load Balancer Scalable File System High Performance Network Smart Management
From what I can tell you get 1 subscription to each of these per basic
subscription (yay complex weird matrix relationships)
John
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On 06/09/2012 12:37 AM, Stephen John Smoogen wrote:
On 8 June 2012 15:50, inode0inode0@gmail.com wrote:
On Fri, Jun 8, 2012 at 5:16 PM, Stephen John Smoogensmooge@gmail.com wrote:
On 8 June 2012 12:14, inode0inode0@gmail.com wrote:
Really confused by this. LB and HA are useful but they are not available to everyone who has a basic RHEL subscription currently.
Well they seem to be available to the people who thought they had a basic subscription. What channels do you see with a basic subscription?
None on this list of Add-On subscriptions.
http://www.redhat.com/products/enterprise-linux-add-ons/
I'd have to double check what you actually do get because it often includes lots of odd-ball channels.
Oh cool. That gives us the matrix of what is available with Red hat Server. Thanks inode0
We are building against Red Hat Enterprise Linux Server which comes with the following add-ons
High Availability Resilient Storage Load Balancer Scalable File System High Performance Network Smart Management
I'm sorry, but this is incorrect. The table at http://www.redhat.com/products/enterprise-linux-add-ons/#features_availabili... lists which add-ons are available for Red Hat Enterprise Server. Available here is not 'included', but more something like 'compatible' and or supported combinations of add-ons.
The additional costs for each add-on is listed here: - http://www.redhat.com/resourcelibrary/articles/articles-red-hat-enterprise-l...
A quote from that page: "You can add optional functionality to a Red Hat Enterprise Linux Server subscription. The following prices are in addition to the price of the underlying Red Hat Enterprise Linux Server subscription."
I think it is important to make a difference between add-on (like High Availability to Red Hat Enterprise Server) and a product (like Red Hat Satellite). IMHO it makes sense to allow EPEL packages with (Build)Requires from the Add-Ons, but not from the products. Products can/may contain different versions (more restrictions) of packages than that are available in the Add-On channels.
Some examples: RHEL customers that do not have the required add-ons (like HA), would have dependency problems for packages from EPEL that require the cluster infrastructure. I doubt that these packages are useful without the cluster bits. RHEL-clones can provide the add-ons as part of their standard distribution, no dependency issues there.
On most (all?) Red Hat Products (like Red Hat Satellite and Storage) customers are not supposed to install additional applications. The products are mostly contained within their own installation. It makes little sense to add EPEL to these servers where a product has been installed.
Therefore, it is possible to allow puppet, glusterfs and the like in EPEL. These packages are part of Red Hat products, and not available in the add-ons. The standard Red Hat Enterprise Server can be enhanced with non-conflicting packages.
Does this make sense to others as well?
Cheers, Niels
Niels de Vos devos@fedoraproject.org wrote:
I think it is important to make a difference between add-on (like High Availability to Red Hat Enterprise Server) and a product (like Red Hat Satellite). IMHO it makes sense to allow EPEL packages with (Build)Requires from the Add-Ons,
Why not just use the add-ons? Especially when they have clearly been in Advanced Server, AS and Advanced Platform and, therefore, EL Rebuilds? Why does EPEL have to now ship them, causing yet another set of conflicts with both Red Hat and EL Rebuild stacks?
When did this view and/or expectation change?
Some examples: RHEL customers that do not have the required add-ons (like HA), would have dependency problems for packages from EPEL that require the cluster infrastructure.
Then customers should do as they always have done ...
Either purchase the RHEL entitlements, or use the EL Rebuilds.
For Fedora EPEL developers/maintainers, Red Hat should provide the necessary entitlements.
I doubt that these packages are useful without the cluster bits.
Exactly! So why is EPEL going there?
RHEL-clones can provide the add-ons as part of their standard distribution, no dependency issues there.
Exactly! So why is EPEL going there?
On most (all?) Red Hat Products (like Red Hat Satellite and Storage) customers are not supposed to install additional applications.
RHN Satellite Server, I largely agree, and that's always been the case. Although I have seen EPEL tapped on RHNS/Spacewalk, but I won't go into that.
But RHN Storage, different story. There has been many customer-facing discussions to the contrary.
The products are mostly contained within their own installation. It make little sense to add EPEL to these servers where a product has been installed.
But it is going to happen, and does.
Therefore, it is possible to allow puppet, glusterfs and the like in EPEL. These packages are part of Red Hat products, and not available in the add-ons. The standard Red Hat Enterprise Server can be enhanced with non-conflicting packages. Does this make sense to others as well?
No, sorry, I have to disagree with most of your statements, especially on the AS/AP components.
-- Bryan
P.S. This is exactly what I was warning about and Seth didn't believe me.
-- Bryan J Smith - Professional, Technical Annoyance
On Mon, Jun 11, 2012 at 1:34 PM, Bryan J Smith b.j.smith@ieee.org wrote:
Niels de Vos devos@fedoraproject.org wrote:
I think it is important to make a difference between add-on (like High Availability to Red Hat Enterprise Server) and a product (like Red Hat Satellite). IMHO it makes sense to allow EPEL packages with (Build)Requires from the Add-Ons,
Why not just use the add-ons? Especially when they have clearly been in Advanced Server, AS and Advanced Platform and, therefore, EL Rebuilds? Why does EPEL have to now ship them, causing yet another set of conflicts with both Red Hat and EL Rebuild stacks?
Advanced Server contained the High-Availability bits, hence these packages could not be included in EPEL. But, it was okay to have (Build)Requires on the HA packages in EPEL.
My suggestion was to keep it this way. The difference is that Advanced Server is not available any longer, and RHEL-6 introduced Add-Ons. I think we can still see the Add-Ons as components of the RHEL Server subscriptions. Not everyone who uses EPEL, had access to the HA (and similar channels), that does not change with the Add-Ons. If someone wants to use RHEL and packages from EPEL that require certain Add-Ons, requiring a subscription (with access to these channels) makes sense to me. If RHEL-clones provide all the requirements (like they probably did already), they won't be affected either.
I am not al all not suggesting that EPEL starts shipping all the packages from all the Add-Ons. I am sorry it came across like that. Personally I see all the Add-Ons (from http://www.redhat.com/products/enterprise-linux-add-ons/#features_availabili...) as part of a RHEL Server installation, and do not like the idea of having the same (and potentially conflicting) packages from EPEL.
Cheers, Niels
On Mon, Jun 11, 2012 at 10:10 AM, Niels de Vos devos@fedoraproject.org wrote:
On Mon, Jun 11, 2012 at 1:34 PM, Bryan J Smith b.j.smith@ieee.org wrote:
Niels de Vos devos@fedoraproject.org wrote:
I think it is important to make a difference between add-on (like High Availability to Red Hat Enterprise Server) and a product (like Red Hat Satellite). IMHO it makes sense to allow EPEL packages with (Build)Requires from the Add-Ons,
Why not just use the add-ons? Especially when they have clearly been in Advanced Server, AS and Advanced Platform and, therefore, EL Rebuilds? Why does EPEL have to now ship them, causing yet another set of conflicts with both Red Hat and EL Rebuild stacks?
Advanced Server contained the High-Availability bits, hence these packages could not be included in EPEL. But, it was okay to have (Build)Requires on the HA packages in EPEL.
My suggestion was to keep it this way. The difference is that Advanced Server is not available any longer, and RHEL-6 introduced Add-Ons. I think we can still see the Add-Ons as components of the RHEL Server subscriptions. Not everyone who uses EPEL, had access to the HA (and similar channels), that does not change with the Add-Ons. If someone wants to use RHEL and packages from EPEL that require certain Add-Ons, requiring a subscription (with access to these channels) makes sense to me. If RHEL-clones provide all the requirements (like they probably did already), they won't be affected either.
I am not al all not suggesting that EPEL starts shipping all the packages from all the Add-Ons. I am sorry it came across like that. Personally I see all the Add-Ons (from http://www.redhat.com/products/enterprise-linux-add-ons/#features_availabili...) as part of a RHEL Server installation, and do not like the idea of having the same (and potentially conflicting) packages from EPEL.
The difference is something built with a dependency on HA bits then would just pull in those dependencies from the user's subscription, now they would just have broken dependencies for RHEL users without the Add-Ons. I don't have any objection at all to treating Add-Ons differently than we treat other Red Hat delivered products like Satellites or Directory and Certificate services. I just don't want to ship things with broken dependencies for RHEL users, so I would actually prefer EPEL also ship any dependencies from the Add-Ons that arise in a way to not conflict with RHEL users who already use those Add-Ons. It seems there is a good plan for doing such a thing already.
John
Neils wrote:
The difference is that Advanced Server is not available any longer, and RHEL-6 introduced Add-Ons.
This isn't actually the case. Add-ons were introduced in RHEL5 before RHEL6, and I'm not just talking RHN Satellite and Directory Server. Several EL Rebuilds moved to support them as well.
E.g., Scalable File System (XFS) in RHEL 5.4/5.5+ (Tech Preview/Release).
inode0 inode0@gmail.com wrote:
The difference is something built with a dependency on HA bits then would just pull in those dependencies from the user's subscription, now they would just have broken dependencies for RHEL users without the Add-Ons.
So you would have Fedora EPEL conflict for those with Red Hat subscriptions, in order to assist those without them? And you would also conflict with EL Rebuilds that include them as well?
That now begs the question if the EL Rebuilds will now just stop building them since they are available in EPEL? If so, now Fedora EPEL becomes the concentrator for EL Rebuilds.
If the packages are truly common, a better pursuit would be to have Red Hat move the packages into the base channel. I have noted that Red Hat has done this mid-release when a case has been made to do such.
inode0 inode0@gmail.com wrote:
I don't have any objection at all to treating Add-Ons differently than we treat other Red Hat delivered products like Satellites or Directory and Certificate services.
So what you're saying is what I said off-list as well. Let's not beat-around-the-bush, and I'm going to be direct ...
We're going to reverse existing policy and reduce the "don't touch" list to the $49-349 Red Hat entitlement offerings. Correct?
People say it's only going to be select packages, but before long, it the entire set. This has already been argued many times on this list as well.
Expectations are extremely fluid here and I see much harm to the entire community-sustaining engineering duality. Many people are arguing the alleged point that Red Hat is "taking away," when it's actually a continued change that is adding more into EPEL, not reducing.
inode0 inode0@gmail.com wrote:
I just don't want to ship things with broken dependencies for RHEL users,
That's going to happen based on the add-on model in general. But as others have put it, in many cases, they are related to the add-ons any way.
If they are not, then there should be a strong case for Red Hat to move them into the base. I would pursue that instead of the intentional conflicts here.
inode0 inode0@gmail.com wrote:
so I would actually prefer EPEL also ship any dependencies from the Add-Ons that arise in a way to not conflict with RHEL users who already use those Add-Ons. It seems there is a good plan for doing such a thing already.
Can you explain this to me? How do we avoid conflicts? Something other than repo preference.
-- Bryan J Smith - Professional, Technical Annoyance
Bryan J Smith wrote:
... That now begs the question if the EL Rebuilds will now just stop building them since they are available in EPEL? If so, now Fedora EPEL becomes the concentrator for EL Rebuilds. ... Expectations are extremely fluid here and I see much harm to the entire community-sustaining engineering duality ... ...
Understand at some point I'm feeling I'm "alone" in many viewpoints and wonder if I should bother any further. I'm surprised many are not seeing my point, but maybe this final attempt will clear it up.
In all of these posts that I have responded to, in countless scenarios put forth, I'm seeing one party ignored over and over, and the only one always ignored.
The paying Red Hat customer who helps fund the sustaining engineering.
In many cases where EPEL build and ships Red Hat packages, even entire add-ons -- things that were in AS/AP, things that were in CentOS Extras, etc... -- the "EL Rebuilds" can just move to ship the EPEL packages instead of having to build their own independent.
So if you are on just a base Red Hat entitlement, or with an EL Rebuild that moves to remove duplications with EPEL, you have no conflicts. But if you are a paying Red Hat customer with add-ons, and many are, you conflict.
Which goes back to my original issue ...
Marginalizing the paying Red Hat customer in the Fedora Project, putting them clearly at the back-of-the-line, which is only self-defeating for the Fedora Project in general.
I think I've beat this like a dead horse at this point.
-- Bryan J Smith - Professional, Technical Annoyance
On Mon, Jun 11, 2012 at 12:13 PM, Bryan J Smith b.j.smith@ieee.org wrote:
Bryan J Smith wrote:
... That now begs the question if the EL Rebuilds will now just stop building them since they are available in EPEL? If so, now Fedora EPEL becomes the concentrator for EL Rebuilds. ... Expectations are extremely fluid here and I see much harm to the entire community-sustaining engineering duality ... ...
Understand at some point I'm feeling I'm "alone" in many viewpoints and wonder if I should bother any further. I'm surprised many are not seeing my point, but maybe this final attempt will clear it up.
In all of these posts that I have responded to, in countless scenarios put forth, I'm seeing one party ignored over and over, and the only one always ignored.
The paying Red Hat customer who helps fund the sustaining engineering.
In many cases where EPEL build and ships Red Hat packages, even entire add-ons -- things that were in AS/AP, things that were in CentOS Extras, etc... -- the "EL Rebuilds" can just move to ship the EPEL packages instead of having to build their own independent.
So if you are on just a base Red Hat entitlement, or with an EL Rebuild that moves to remove duplications with EPEL, you have no conflicts. But if you are a paying Red Hat customer with add-ons, and many are, you conflict.
Which goes back to my original issue ...
Marginalizing the paying Red Hat customer in the Fedora Project, putting them clearly at the back-of-the-line, which is only self-defeating for the Fedora Project in general.
I think you misunderstand me. I am doing the opposite of marginalizing the paying Red Hat customer from my perspective. I am trying to minimize any issues that affect RHEL customers.
Many RHEL customers now do not have Add-Ons. I think Add-Ons in my ideal world would be off limits for EPEL. By excluding them from EPEL we cause no problems to any RHEL customers.
Now the argument is made by others, and I think it is a reasonable position to take, that the EPEL community feels that too severely restricts them in a variety of ways including building packages that aren't part of RHEL but which have a dependency that is entangled.
So given the drift that I sense in the EPEL community I am offering compromises that I am comfortable with (of course the EPEL community will make decisions). I really see benefit and no harm at all to RHEL customers if when an EPEL packager finds a dependency in Add-On X for his package he also rebuilds whatever is necessary to satisfy that dependency and includes that in EPEL. The prior suggestion of this likely being a rebuild of the entangled RHEL Add-On package but versioned lower than the Add-On package makes it not conflict with anyone using the Add-On and makes other useful software work.
John
inode0 inode0@gmail.com wrote:
I think you misunderstand me. I am doing the opposite of marginalizing the paying Red Hat customer from my perspective. I am trying to minimize any issues that affect RHEL customers. Many RHEL customers now do not have Add-Ons.
Actually, many do, just not 1:1 with all base entitlements. I think you're ignoring that reality. But that's another discussion (one I've already touched on prior).
I think you need to step back and ask yourself why Red Hat has add-ons in the first place? Why did Red Hat do Advanced Server, AS and Advanced Platform at all?
My continued issue is that we want to expense those customers that fund Red Hat's sustaining engineering first, and think of those who either do not, or to a lesser extent. That's self-defeating, and I'm beating this like a dead horse, and feel I should not. Really, I wish others could see that very, very potent point.
Now if there is a case for a package in an add-on to be a library or other support "common" to many considerations, then the case should be made for that package to be in the "base" channel. Until then, there's a reason why it's in the add-on.
I think Add-Ons in my ideal world would be off limits for EPEL. By excluding them from EPEL we cause no problems to any RHEL customers.
I just do not think EPEL is the solution here. I must really be mistaken on EPEL's history myself. I know many others are, so I am not alone. If we are attempting to provide a solution for both Red Hat customers and community alike, there must be a line drawn on dependencies.
What continues to bother me is that I keep seeing a lot of favoritism shown towards those who do not fund Red Hat's additional, sustaining engineering efforts beyond base. I think it should at least be _equal_ consideration for those who do.
The "expectations" on this have been all over the place.
First it was Red Hat customers shouldn't be using EPEL (well then, who is EPEL for?). Then it's just Red Hat customers who only use base (well the, who is EPEL for?). But I've beaten the horse on why they are important, and not ones to marginalize. Now we're really throwing a lot of asterisks.
My continued view is that the SRPMS are there, and the EL Rebuilds can provide them. There's even been CentOS Extras and others that have shipped add-ons too. Sure, you can draw a line on add-ons v. products. But a lot of people are arguing the add-ons for dependencies, when I keep trying to point out that those customers that provide more Red Hat funding will be marginalized the most.
I really feel like I shouldn't have to point that out. It bothers me that I have to. Really?
Now the argument is made by others, and I think it is a reasonable position to take, that the EPEL community feels that too severely restricts them in a variety of ways including building packages that aren't part of RHEL but which have a dependency that is entangled.
If EPEL is to be a concentration point for community and EL Rebuilds, then that's what it is. I'll accept it and advise my clients and customers to avoid it. I just need to have that "hammer comes down" and move on.
Otherwise, until the "hammer comes down," I'm just pointing out why I think it's self-defeating and will cause various issues for Red Hat customers. Dead horse x10 here.
So given the drift that I sense in the EPEL community I am offering compromises that I am comfortable with (of course the EPEL community will make decisions). I really see benefit and no harm at all to RHEL customers if when an EPEL packager finds a dependency in Add-On X for his package he also rebuilds whatever is necessary to satisfy that dependency and includes that in EPEL.
Let's separate two (2) things ...
1) EPEL user, from 2) EPEL developer/maintainer
It's very important not to confuse #2 with #1.
#1 should either be utilizing Red Hat entitlements, or considering an EL Rebuild. That way there are no conflicts for either. If you start including things in EPEL, then the EL Rebuilds will just use the EPEL ones, but then that doesn't bode well for Red Hat customers who want to fund that additional, sustaining engineering.
But in the case of #2, which I believe you are stating here, it should be on Red Hat -- via Fedora Project leaders -- to provide the necessary entitlements for add-ons to develop and maintain. I've been lauding this for some time now. Fedora EPEL developer and maintainers _absolutely_ need Red Hat entitlements and it's in Red Hat's interest to provide them free-of-charge.
So let's not confuse #2 with #1.
The prior suggestion of this likely being a rebuild of the entangled RHEL Add-On package but versioned lower than the Add-On package makes it not conflict with anyone using the Add-On and makes other useful software work.
Somehow that really doesn't seem to click well with me. I can state several reasons, but I don't see it working.
At the same time, if the version is different, it will at least reduce some of the load on Red Hat services and support when they run into such. I'll admit that. But it would be nice to eliminate the possibility.
Or at least have an user/sysadmin have to tap an EL Rebuild, knowingly that they have.
-- Bryan J Smith - Professional, Technical Annoyance http://www.linkedin.com/in/bjsmith
On Mon, Jun 11, 2012 at 1:38 PM, Bryan J Smith b.j.smith@ieee.org wrote:
inode0 inode0@gmail.com wrote:
I think you misunderstand me. I am doing the opposite of marginalizing the paying Red Hat customer from my perspective. I am trying to minimize any issues that affect RHEL customers. Many RHEL customers now do not have Add-Ons.
Actually, many do, just not 1:1 with all base entitlements. I think you're ignoring that reality. But that's another discussion (one I've already touched on prior).
I completely agree that many do. So we don't need to argue about that point.
I think you need to step back and ask yourself why Red Hat has add-ons in the first place? Why did Red Hat do Advanced Server, AS and Advanced Platform at all?
I already have explained why I was told Red Hat has Add-Ons.
My continued issue is that we want to expense those customers that fund Red Hat's sustaining engineering first, and think of those who either do not, or to a lesser extent. That's self-defeating, and I'm beating this like a dead horse, and feel I should not. Really, I wish others could see that very, very potent point.
I don't see how this proposal is at anyone's expense. How does it cause a problem for any paying Red Hat customer?
Now if there is a case for a package in an add-on to be a library or other support "common" to many considerations, then the case should be made for that package to be in the "base" channel. Until then, there's a reason why it's in the add-on.
That is fine. People can make that case and if and when it is moved to base it can be removed from EPEL. No problem.
I think Add-Ons in my ideal world would be off limits for EPEL. By excluding them from EPEL we cause no problems to any RHEL customers.
I just do not think EPEL is the solution here. I must really be mistaken on EPEL's history myself. I know many others are, so I am not alone. If we are attempting to provide a solution for both Red Hat customers and community alike, there must be a line drawn on dependencies.
That seems to be what we are discussing, where to draw that line.
What continues to bother me is that I keep seeing a lot of favoritism shown towards those who do not fund Red Hat's additional, sustaining engineering efforts beyond base. I think it should at least be _equal_ consideration for those who do.
I don't understand this. Everything I suggest is based on my desire to not cause problems for *ANY* RHEL customer while enabling the addition via EPEL of as many useful extra packages as possible.
The "expectations" on this have been all over the place.
First it was Red Hat customers shouldn't be using EPEL (well then, who is EPEL for?). Then it's just Red Hat customers who only use base (well the, who is EPEL for?). But I've beaten the horse on why they are important, and not ones to marginalize. Now we're really throwing a lot of asterisks.
My continued view is that the SRPMS are there, and the EL Rebuilds can provide them. There's even been CentOS Extras and others that have shipped add-ons too. Sure, you can draw a line on add-ons v. products. But a lot of people are arguing the add-ons for dependencies, when I keep trying to point out that those customers that provide more Red Hat funding will be marginalized the most.
I just do not see how this marginalizes them. It benefits them by making extra packages available to them via EPEL.
I really feel like I shouldn't have to point that out. It bothers me that I have to. Really?
Now the argument is made by others, and I think it is a reasonable position to take, that the EPEL community feels that too severely restricts them in a variety of ways including building packages that aren't part of RHEL but which have a dependency that is entangled.
If EPEL is to be a concentration point for community and EL Rebuilds, then that's what it is. I'll accept it and advise my clients and customers to avoid it. I just need to have that "hammer comes down" and move on.
That isn't the point at all and I can't believe any rebuild of RHEL is going to tell its users to go get package X from EPEL when the rebuild can provide it directly (like a library that gets rebuilt in EPEL from an Add-On channel).
Otherwise, until the "hammer comes down," I'm just pointing out why I think it's self-defeating and will cause various issues for Red Hat customers. Dead horse x10 here.
So given the drift that I sense in the EPEL community I am offering compromises that I am comfortable with (of course the EPEL community will make decisions). I really see benefit and no harm at all to RHEL customers if when an EPEL packager finds a dependency in Add-On X for his package he also rebuilds whatever is necessary to satisfy that dependency and includes that in EPEL.
Let's separate two (2) things ...
- EPEL user, from
- EPEL developer/maintainer
It's very important not to confuse #2 with #1.
It is also very important to not miss the fact that without #2 there is no #1.
#1 should either be utilizing Red Hat entitlements, or considering an EL Rebuild. That way there are no conflicts for either. If you start including things in EPEL, then the EL Rebuilds will just use the EPEL ones, but then that doesn't bode well for Red Hat customers who want to fund that additional, sustaining engineering.
But in the case of #2, which I believe you are stating here, it should be on Red Hat -- via Fedora Project leaders -- to provide the necessary entitlements for add-ons to develop and maintain. I've been lauding this for some time now. Fedora EPEL developer and maintainers _absolutely_ need Red Hat entitlements and it's in Red Hat's interest to provide them free-of-charge.
They do provide them and they are included in the current build system if I understand.
So let's not confuse #2 with #1.
The prior suggestion of this likely being a rebuild of the entangled RHEL Add-On package but versioned lower than the Add-On package makes it not conflict with anyone using the Add-On and makes other useful software work.
Somehow that really doesn't seem to click well with me. I can state several reasons, but I don't see it working.
At the same time, if the version is different, it will at least reduce some of the load on Red Hat services and support when they run into such. I'll admit that. But it would be nice to eliminate the possibility.
EPEL can't solve this problem for Red Hat support. We all understand the issue. We don't want to cause hardship on support or any other part of Red Hat's operations. But I think we are past "don't ever release any package that Red Hat releases anywhere" now. That ship has sailed.
John
epel-devel@lists.fedoraproject.org