FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > EPEL Development

 
 
LinkBack Thread Tools
 
Old 05-29-2012, 05:04 AM
inode0
 
Default Thoughts from last meeting

On Mon, May 28, 2012 at 11:42 PM, Stephen John Smoogen <smooge@gmail.com> wrote:
> On 28 May 2012 20:16, inode0 <inode0@gmail.com> wrote:
>> On Mon, May 28, 2012 at 6:53 PM, Toshio Kuratomi <a.badger@gmail.com> wrote:
>>> On Fri, May 25, 2012 at 04:45:39PM -0500, inode0 wrote:
>>>> On Fri, May 25, 2012 at 4:24 PM, Kevin Fenzi <kevin@scrye.com> wrote:
>>>>
>>>> > Anyhow, thoughts? concerns?
>>>>
>>>> As an EPEL consumer I find this all rather confusing. I don't want to
>>>> have to know which layered products are protected and which aren't. I
>>>> think I'd rather live with a simpler uniform policy regarding layered
>>>> products.
>>>>
>>> As a non-administrator of RHEL I find it confusing too. *I don't know what
>>> fee structure and other non-repository divisions occur between base RHEL and
>>> layered products and whether they are the same for all layered products or
>>> only some.
>>
>> The nature of layered products is changing as RHEL is offered as more
>> of an a la carte product now. While EPEL including something like
>> puppet isn't such a big concern to me as it is a small component of a
>> larger offering from Red Hat, EPEL providing piranha + ipvsadm which
>> comprise the Load Balancer Add-On is a much bigger concern to me. I
>> don't really think EPEL should put Red Hat in the position of having
>> to ask for it to be removed. So unless we know that including such
>> things is fine with Red Hat in advance I think we should exclude them
>> as EPEL providing complete "layered products" or "Red Hat Enterprise
>> Linux Add-Ons" seems like crossing a line we shouldn't cross to me.
>
> Well then the only way I can see to meet your point would be to stop EPEL.

I'm not sure it is that dire. Do we know if Red Hat cares about EPEL
providing complete RHEL Add-Ons? If they don't then my concern is
gone.

> There are very very few packages left after the conflicting packages
> and their requirements are pulled. You can't include any of the other
> configuration management tools because they also use pulled in
> libraries (augeus and such). Anything with Perl dependencies are
> pulled from other items in the layered products. And since many of the
> items that would be left are supported by maintainers whose main
> packages would be pulled.. I doubt they would want to support those
> eithers. It quickly becomes a cascade of pulls to the point where it
> is not worth keeping going.

I can imagine pulling in libraries needed as dependencies to be viewed
as ok while completely replacing RHEL Add-Ons not being viewed as ok.
There may be some middle ground even if EPEL doesn't provide RHEL
Add-Ons.

John

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-29-2012, 01:07 PM
Bryan J Smith
 
Default Thoughts from last meeting

inode0 <inode0@gmail.com> wrote:
> I'm not sure it is that dire. Do we know if Red Hat cares about EPEL
> providing complete RHEL Add-Ons? If they don't then my concern is
> gone.
> I can imagine pulling in libraries needed as dependencies to be viewed
> as ok while completely replacing RHEL Add-Ons not being viewed as ok.
> There may be some middle ground even if EPEL doesn't provide RHEL
> Add-Ons.

If I may be so bold, I believe some (not yourself) are looking at this
the wrong way. The way I have always looked at it, the Fedora Project
is really designed to help Red Hat, both upstream and downstream, as
much as the community. In that regard, we should really get past this
"worry," and get to the bigger issue, even for Red Hat, as much as
downstream.

I think you're hitting on it well here, so let me expand on my view if
I may. Many in the EPEL SIG have already identified a lot of
conflicts and issues, things that I feel Red Hat could benefit from.
In my experience, Red Hat can always use more input and assistance. I
think has been obvious ever since Red Hat Linux 10 Beta became Fedora
Core 1 Test, at least to me.

So I honestly believe the answer lies in a more direct engagement with
Red Hat product and release management. Most specifically, leverage
the EPEL community SMEs to identify:
1. common support libraries and components which should be in RHEL
base channels
2. resulting conflicts between support libraries and components in
RHEL layered channels
3. package and other naming conventions to address possible needs for
multiple versions

All of these details work in favor of RHEL as much as the EPEL SIG
downstream. Let's make that point clear with Red Hat, it's that
"extra set of broad eyes." I am willing to assist any way I can,
since I'm heavily customer-facing and this continually affects large
Red Hat customers. This is really a case where the Fedora Project can
and does holds extensive value-add, and it's clear Red Hat could use
some input at times.

BTW, this is in addition to my personal and continuing favorite (some
of you have heard me harp on this via other avenues) ...
- Facilitate easier access not just to RHEL entitlements for EPEL
maintainers, but layered entitlements too -- e.g., a "pool" that can
be assigned by Fedora Project leaders

My view has been the "gold standard" for development and builds in
EPEL should be RHEL+layered entitlements. Red Hat only shoots itself
in-the-foot if it doesn't not make them readily available to EPEL
developers. It also gets back valuable feedback, things that help Red
Hat avoid issues with its own customers. It's win-win-win for Red
Hat-customer-community to do so, and that has been my long-standard,
long-held view.

As always, my views are my own only.


--
Bryan J Smith - Professional, Technical Annoyance

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-29-2012, 01:34 PM
Stephen John Smoogen
 
Default Thoughts from last meeting

On 28 May 2012 23:04, inode0 <inode0@gmail.com> wrote:

>> Well then the only way I can see to meet your point would be to stop EPEL.
>
> I'm not sure it is that dire. Do we know if Red Hat cares about EPEL
> providing complete RHEL Add-Ons? If they don't then my concern is
> gone.
>

As in all cases, there is no Red Hat, there are 4000 different Red
Hatters. We have groups (like IPA, Directory Services, Gluster, and
some others) who rely on EPEL so that they can give customer who want
to see where things are going but don't run Fedora because it is too
far advanced from what they are running. You have other groups who
really don't care and say "Well if someone is running EPEL and our
conflicts, that is their problem." and we have consultants who end up
having to fix those problems. And finally you have EPEL being a
project run on Fedora servers by volunteers. None of us are paid to
work on it, even in Fedora Infrastructure. We do so because it fits
our needs, is useful to us, and for the most part is fun. Remove those
and there is no need for it.

In order for EPEL to build against those channels it would require
changes to Koji and the infrastructure. Some of the channels are not
meant to be run on the same channel (one provides foo-1.2.3 and
another provides foo-2.1.3.) it will require knowing that if you are
building X that you required foo-2 and not foo-1 (or vice versa).



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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-29-2012, 01:40 PM
seth vidal
 
Default Thoughts from last meeting

On Sat, 26 May 2012 12:24:14 -0400
Jon Stanley <jonstanley@gmail.com> wrote:
> I agree with the sentiment, but it can help that even without
> explicitly avoiding every single bit of package overlap.Do I think
> that EPEL should ship a new kernel, coreutils, etc? Of course not. But
> I don't think that EPEL should be categorically prohibited from
> shipping something that overlaps with something else that is not RHEL
> that Red Hat sells. I consider the layered entitlements (including
> cluster and lb) to *not* be a part of RHEL - they are part of a
> different product, sold and priced differently (the fact that you have
> to have the base product in order to buy the layered ones makes no
> difference either - I have to have a car, or else buying floormats
> doesn't make any sense).
>
> So to put it in concrete terms, I advocate that EPEL does not ship
> anything that is in -server and -server-optional. Anything else is
> fair game, unless explicitly asked by Red Hat to remove the bits.
>


I have been lurking along for a while here but I would like to put in
my 2cents.

I think Jon's proposal above:

inclusive of what epel's default limits are, disallowing of exact
rebuilds of any srpm from any channel and allowing for notification
from red hat through a specific and established source (his example
of spot is a good one but we don't need to necessarily throw spot
under the bus, other folks could be the epel-go-between too)

is a good proposal. I think it is consistent, easy to understand and to
explain and will help epel thrive.

my 2cents. I speak only for me not for my employer.

-sv

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-29-2012, 02:16 PM
Jan-Frode Myklebust
 
Default Thoughts from last meeting

On Fri, May 25, 2012 at 05:25:58PM -0500, inode0 wrote:
>
> My general preference as a consumer of both RHEL and EPEL would be in order:
>
> 1 - EPEL does not conflict with RHEL + Layered Products (all Layered Products)
>
> I know that holds some important things back that lots of folks benefit from.
>
> 2 - EPEL does not conflict with RHEL base packages (base being loosely
> defined as what comes with a standard RHEL subscription, so would in
> the case of RHEL6 include the optional channel for example).

<snip>

> I would be really happy also with EPEL doing 1 for its primary
> repository but also providing a secondary repository where all Layered
> Products can be trumped by EPEL versions. Separating those conflicts
> into a secondary repo would be a big help to EPEL's downstream users I
> think.

I completely agree. Secondary repo which would be disabled by default
holding packages that could conflict with RH-channels would be ideal for
our usage. It would also open up for actively including stuff that's in
RHEL layered products -- for unsupported usage.

I also wish for an epel-bleeding-edge repo, that could contain latest
upstream versions of select packages that are in base rhel. We f.ex. pick the
latest dovecot from the package-db and build for EL6 locally. Having this
in an EPEL-channel were we could get more users/tester/quality would be great.


-jf

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-29-2012, 02:31 PM
inode0
 
Default Thoughts from last meeting

On Tue, May 29, 2012 at 8:40 AM, seth vidal <skvidal@fedoraproject.org> wrote:
> On Sat, 26 May 2012 12:24:14 -0400
> Jon Stanley <jonstanley@gmail.com> wrote:
>> I agree with the sentiment, but it can help that even without
>> explicitly avoiding every single bit of package overlap.Do I think
>> that EPEL should ship a new kernel, coreutils, etc? Of course not. But
>> I don't think that EPEL should be categorically prohibited from
>> shipping something that overlaps with something else that is not RHEL
>> that Red Hat sells. I consider the layered entitlements (including
>> cluster and lb) to *not* be a part of RHEL - they are part of a
>> different product, sold and priced differently (the fact that you have
>> to have the base product in order to buy the layered ones makes no
>> difference either - I have to have a car, or else buying floormats
>> doesn't make any sense).

The notion of layered products in my mind got cloudy with the
introduction of the Red Hat Enterprise LInux Add-On category. While I
don't see layered products like those dealing with identity management
(certificate system, directory server) as being part of RHEL it is
hard for me to see the newer RHEL Add-Ons like Load Balancer as being
not part of RHEL. They seem to be the result of customers wanting a
lower cost basic version of RHEL that doesn't include all the bells
and whistles while allowing RHEL users with different needs to include
those bells and whistles from a menu of available parts of RHEL not
included in the lowest cost version. To me it is just like the old AS
vs. ES distinction but offered through a menu of add-ons rather than
through different versions of RHEL. This is marketing more than
anything else.

>> So to put it in concrete terms, I advocate that EPEL does not ship
>> anything that is in -server and -server-optional. Anything else is
>> fair game, unless explicitly asked by Red Hat to remove the bits.
>>
>
>
> I have been lurking along for a while here but I would like to put in
> my 2cents.
>
> I think Jon's proposal above:
>
> * inclusive of what epel's default limits are, disallowing of exact
> * rebuilds of any srpm from any channel and allowing for notification
> * from red hat through a specific and established source (his example
> * of spot is a good one but we don't need to necessarily throw spot
> * under the bus, other folks could be the epel-go-between too)
>
> is a good proposal. I think it is consistent, easy to understand and to
> explain and will help epel thrive.

This is certainly easy to understand and my only concern is from the
perspective of the EPEL consumer. If the Load Balancer Add-On were
provided by EPEL and I jumped on that only to have the epel-go-between
object 6 months later and have it pulled out from under me I would be
an unhappy camper. It is OK to say that is my tough luck, but in cases
like this I'd feel more confident using EPEL if the epel-go-between
said it was OK to include Load Balancer Add-On before it was included
rather than coming along later to say it isn't OK and yanking it.

John

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-29-2012, 02:33 PM
Chris Adams
 
Default Thoughts from last meeting

Once upon a time, inode0 <inode0@gmail.com> said:
> larger offering from Red Hat, EPEL providing piranha + ipvsadm which
> comprise the Load Balancer Add-On is a much bigger concern to me. I
> don't really think EPEL should put Red Hat in the position of having
> to ask for it to be removed. So unless we know that including such
> things is fine with Red Hat in advance I think we should exclude them
> as EPEL providing complete "layered products" or "Red Hat Enterprise
> Linux Add-Ons" seems like crossing a line we shouldn't cross to me.

Um, it is all Open Source software, so if a third party (EPEL or
somebody else) wants to also provide it, Red Hat doesn't really have a
leg to stand on asking it to be removed. You are perfectly within your
rights to purchase RHEL entitlements and load whatever software you
want, even software that Red Hat offers to support at additional cost,
without paying them any more money (you just won't get any support for
it).

If you don't like that, then don't use EPEL (or any other third party
software repository).

--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-29-2012, 02:38 PM
seth vidal
 
Default Thoughts from last meeting

On Tue, 29 May 2012 09:33:11 -0500
Chris Adams <cmadams@hiwaay.net> wrote:

> Once upon a time, inode0 <inode0@gmail.com> said:
> > larger offering from Red Hat, EPEL providing piranha + ipvsadm which
> > comprise the Load Balancer Add-On is a much bigger concern to me. I
> > don't really think EPEL should put Red Hat in the position of having
> > to ask for it to be removed. So unless we know that including such
> > things is fine with Red Hat in advance I think we should exclude
> > them as EPEL providing complete "layered products" or "Red Hat
> > Enterprise Linux Add-Ons" seems like crossing a line we shouldn't
> > cross to me.
>
> Um, it is all Open Source software, so if a third party (EPEL or
> somebody else) wants to also provide it, Red Hat doesn't really have a
> leg to stand on asking it to be removed. You are perfectly within
> your rights to purchase RHEL entitlements and load whatever software
> you want, even software that Red Hat offers to support at additional
> cost, without paying them any more money (you just won't get any
> support for it).
>
> If you don't like that, then don't use EPEL (or any other third party
> software repository).
>


I think the point here is that no one wants to take a 'tough luck'
position or any such dramatic statements. We're providing software
packages to people who are, overwhelmingly, running servers that need
to be stable. They are just looking for stability and consistency.

So I think we don't want to make any dramatic statements about whether
or not red hat has a right to ask to have something removed. 1. it is
probably unnecessary 2. it just doesn't help our core user base.

which is why I like Jon's proposal - it's simple and doesn't involve
dramatic statements of any kind. It's how I would like my own servers
to run: low key and straightforward.

-sv

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-29-2012, 02:44 PM
Chris Adams
 
Default Thoughts from last meeting

Once upon a time, Jan-Frode Myklebust <janfrode@tanso.net> said:
> I completely agree. Secondary repo which would be disabled by default
> holding packages that could conflict with RH-channels would be ideal for
> our usage. It would also open up for actively including stuff that's in
> RHEL layered products -- for unsupported usage.

The problem with that is you'd need an ever-increasing combination of
additional EPEL repos. There'd be an "EPEL base" that doesn't conflict
with any layered products (but has almost no packages), but then you'd
need a bunch of combinations of "doesn't conflict with foo and bar but
may conflict with baz".

If there are RH layered products that can conflict with each other (as I
believe somebody said there may be), it becomes an even more impossible
problem to solve.

IIRC somebody suggested yum-priorities. I think that that is the only
sane way to go; make epel-release require yum-priorities and set EPEL (a
single repo) to a lower priority than then RHN channels. Let EPEL
maintainers decide what they want to maintain and "let the buyer beware"
if somebody fiddles with EPEL priorities. There are just too many
potential combinations of conflicts to try to handle any other way.

That way, if RH directory server folks want to maintain a set of
packages in EPEL as well, they can do so, and explain to their customers
how to use them (which would basically be "unsubscribe your test systems
from the directory server layered product RHN channel").

--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-29-2012, 02:51 PM
Bryan J Smith
 
Default Thoughts from last meeting

Chris Adams wrote:
> Um, it is all Open Source software, so if a third party (EPEL

Just keep in mind that the Fedora Project is quite differentiated from
other Third Party Software (TPS) by many people, including community
TPS repositories. From post #1, I've tried to put for the reasons why
marginalizing Red Hat customers is not the way to go in the Red Hat
sponsored Fedora Project.

> or somebody else) wants to also provide it,

Indeed. The question becomes where do people get it in a way that it
does not sprawl "out-of-control" from the standpoint of management.
You have to consider not just ...
A. Red Hat desktop subscriptions
B. Red Hat server subscriptions
C. Red Hat server subscriptions with optional enterprise channels
(pricing up to 10x as much as "B", a pricing/support differential
which has existed since RHEL 2.1)

But also ...
D. EL Rebuilds who strive for bit-for-bit compatibilit y(who vary in
what they have in base, extras, etc...)
E. Other projects that may or may not be involved

> Red Hat doesn't really have a leg to stand on asking it to be removed.

Again, why go there? I've never considered it to be "versus" in the
Fedora Project, but trying to address the needs of Red Hat, customers
and community. This helps no one.

>*You are perfectly within your rights to purchase RHEL entitlements and
> load whatever software you want, even software that Red Hat offers to
> support at additional cost, without paying them any more money (you
> just won't get any support for it).

Unfortunately, people do, not just intentionally, but unintentionally.
Red Hat wastes resources, etc... And it's not the community that is
really the concern, but more costly, proprietary vendors that
intentionally put customers and community in the position of doing it,
unintentionally.

If it is at all possible, I would advocate the Fedora Project provide
diligence in mitigating this issue. Several people have many solid
suggestions on how to mitigate this, even though it will still happen.
The idea is to do what is technically and managerially possible to
mitigate it, and that's all the Fedora Project can do.

> If you don't like that, then don't use EPEL (or any other third party
> software repository).

The more you ignore the needs of one entity/userbase, the more you
marginalize them, the more it loses value. This is hardly about
"having a leg to stand on," so don't go there.


--
Bryan J Smith - Professional, Technical Annoyance

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 

Thread Tools




All times are GMT. The time now is 01:53 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org