12:35 p.m.
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
12:43 p.m.
On Fri, Jun 8, 2012 at 10:35 AM, Toshio Kuratomi <a.badger(a)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
1:14 p.m.
On Fri, Jun 8, 2012 at 1:35 PM, Toshio Kuratomi <a.badger(a)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
1:39 p.m.
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(a)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:
http://fpaste.org/xAPF/
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
1:52 p.m.
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(a)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:
http://fpaste.org/xAPF/
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).
2 p.m.
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
4:58 p.m.
On Fri, Jun 8, 2012 at 2:39 PM, Toshio Kuratomi <a.badger(a)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:
http://fpaste.org/xAPF/
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
11:51 p.m.
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
4:16 p.m.
On 8 June 2012 12:14, inode0 <inode0(a)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?
--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
4:50 p.m.
On Fri, Jun 8, 2012 at 5:16 PM, Stephen John Smoogen <smooge(a)gmail.com> wrote:
On 8 June 2012 12:14, inode0 <inode0(a)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
5:37 p.m.
On 8 June 2012 15:50, inode0 <inode0(a)gmail.com> wrote:
On Fri, Jun 8, 2012 at 5:16 PM, Stephen John Smoogen
<smooge(a)gmail.com> wrote:
> On 8 June 2012 12:14, inode0 <inode0(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
4:23 a.m.
On 06/09/2012 12:37 AM, Stephen John Smoogen wrote:
On 8 June 2012 15:50, inode0<inode0(a)gmail.com> wrote:
> On Fri, Jun 8, 2012 at 5:16 PM, Stephen John Smoogen<smooge(a)gmail.com> wrote:
>> On 8 June 2012 12:14, inode0<inode0(a)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_availab...
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-enterpris...
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
6:34 a.m.
Niels de Vos <devos(a)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
10:10 a.m.
On Mon, Jun 11, 2012 at 1:34 PM, Bryan J Smith <b.j.smith(a)ieee.org> wrote:
Niels de Vos <devos(a)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_availab...)
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
10:18 a.m.
On Mon, Jun 11, 2012 at 10:10 AM, Niels de Vos <devos(a)fedoraproject.org> wrote:
On Mon, Jun 11, 2012 at 1:34 PM, Bryan J Smith
<b.j.smith(a)ieee.org> wrote:
> Niels de Vos <devos(a)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_availab...)
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
10:40 a.m.
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(a)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(a)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(a)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(a)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
12:13 p.m.
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
1:13 p.m.
On Mon, Jun 11, 2012 at 12:13 PM, Bryan J Smith <b.j.smith(a)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
1:38 p.m.
inode0 <inode0(a)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
3:34 p.m.
On Mon, Jun 11, 2012 at 1:38 PM, Bryan J Smith <b.j.smith(a)ieee.org> wrote:
inode0 <inode0(a)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 ...
1) EPEL user, from
2) 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
4335
days inactive
4338
days old
epel-devel@lists.fedoraproject.org
19 comments
6 participants
participants (6)
-
Bryan Smith -
inode0 -
Niels de Vos -
Stephen Gallagher -
Stephen John Smoogen -
Toshio Kuratomi