On 23 May 2012 14:54, Bryan J Smith <b.j.smith(a)ieee.org> wrote:
Stephen John Smoogen wrote:
> I think that for customers using layered products it would be smarter
> to avoid outside repositories anyway.
That would then remove the value of an option from the Fedora
community like EPEL. That's why I asked prior what the purpose of
EPEL is, regardless of any prior assumptions or statements. If it is
going to deliver layered products, I will have to advise enterprises
of those details.
Well here is the issue. We have been delivering layered products for a
long time (probably since the beginning) mainly because various groups
did not want to do an Emerging Technologies for Enterprise Linux.
> If a customer is using layered items onto the OS they are going
to need
> to make sure they have only Red Hat supported software installed.
So that now brings up another question ...
If they only have the base entitlement product installed, this is not the case?
I.e., if they have no layered products, they can use EPEL. But if
they do, they can't?
And if we have difficulty with that question, is it really Extra
Package for Enterprise Linux (EPEL) any more?
Hey they can use whatever they want. It is up to entities I have no
say or control in whether it will be supported by either consultants
or Red Hat support.
The issue is that if EPEL pulls out core packages every time Red Hat
decides to offer a sub-channel of supported, then there is no need for
EPEL since it will get gutted regularly. At this point we are looking
at 1/3->1/2 of EPEL having to be removed because packages require or
buildrequire items that are included in layered products that would no
longer be available to build against. Which leads me to my first
statement, that the usability of EPEL to a layered user is much less
than a base OS user.
> Even if we were to somehow remove all the conflicts we can't
remove
> secondary problems where software if it finds libXYZ installed will manually
> load that even if it is not included with RHEL.
Ideally layered products should push any libraries, those shared
between or utilized between layers, into the base OS for support.
That way there is no question what should and should not conflict with
a Fedora SIG like EPEL, assuming the guidelines are to avoid such.
I stress "ideally" because we all know how long any product release
considerations, let alone changes, take to verify countless items and
make those types of decisions.
> [Various gnome apps do this so I expect other software will also end up
> with such "plugin" architectures.]
Indeed. But then we run into the related issues where Fedora is more
leading edge, and EPEL uses something more leading edge. But there
are still some customers who want those additional plug-ins for the
trailing edge versions in RHEL or its layered products, but those
plug-ins do not ship with them.
_______________________________________________
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