1:35 p.m.
As the subject notes, nagios is in fact shipped by RedHat.
Details
Description: Nagios is a program that will monitor hosts and services on your
network. It has the ability to send email or page alerts when a
problem arises and when a problem is resolved. Nagios is written
in C and is designed to run under Linux (and some other *NIX
variants) as a background process, intermittently running checks
on various services that you specify.
The actual service checks are performed by separate "plugin" programs
which return the status of the checks to Nagios. The plugins are
available at http://sourceforge.net/projects/nagiosplug.
This package provides the core program, web interface, and documentation
files for Nagios. Development files are built as a separate package.
Arch: AMD64
Available Archs: AMD64
Available From: Red Hat HPC Solution (v. 5 for 64-bit x86_64)
Vendor: Red Hat, Inc.
Source RPM: nagios-2.12-6.1.el5.src.rpm
MD5 Sum: 993fd4eb767f0981c662637a7f53a009
Package Size: 2,302,710 bytes
Payload Size: 5,328,032 bytes
Build Host: hs20-bc2-5.build.redhat.com
Build Date: 10/12/09 7:39:15 AM PDT
License: GPLv2
Group: Applications/System
RPM Version: 4.4.2.3
The reason I wanted to bring this up is that we say in our policy that
we do not ship packages that are shipped by RedHat in RHEL. But this
being a subscription channel that is not extremely popular, do we want
to revise that policy to say that we don't ship packages that are not
in the base channel of desktop/workstation/server/ap as those are the
most common or do we want to stick to the current policy quite
strictly?
Just food for thought, it was a topic of conversation in #rhel today.
-AdamM
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
3:27 p.m.
On Mon, Jan 11, 2010 at 12:35 PM, Adam Miller
<maxamillion(a)fedoraproject.org> wrote:
As the subject notes, nagios is in fact shipped by RedHat.
.....
The reason I wanted to bring this up is that we say in our policy
that
we do not ship packages that are shipped by RedHat in RHEL. But this
being a subscription channel that is not extremely popular, do we want
to revise that policy to say that we don't ship packages that are not
in the base channel of desktop/workstation/server/ap as those are the
most common or do we want to stick to the current policy quite
strictly?
As I understood it.. it was only for the base RHEL channels. Channels
which are not available from a base subscription were not considered
covered by our policy.
Just food for thought, it was a topic of conversation in #rhel
today.
-AdamM
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
_______________________________________________
epel-devel-list mailing list
epel-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
3:40 p.m.
On Mon, Jan 11, 2010 at 3:27 PM, Stephen John Smoogen <smooge(a)gmail.com> wrote:
On Mon, Jan 11, 2010 at 12:35 PM, Adam Miller
<maxamillion(a)fedoraproject.org> wrote:
> As the subject notes, nagios is in fact shipped by RedHat.
>
.....
> The reason I wanted to bring this up is that we say in our policy that
> we do not ship packages that are shipped by RedHat in RHEL. But this
> being a subscription channel that is not extremely popular, do we want
> to revise that policy to say that we don't ship packages that are not
> in the base channel of desktop/workstation/server/ap as those are the
> most common or do we want to stick to the current policy quite
> strictly?
As I understood it.. it was only for the base RHEL channels. Channels
which are not available from a base subscription were not considered
covered by our policy.
https://fedoraproject.org/wiki/EPEL/FAQ#How_is_EPEL_different_from_other_...
Third bullet point down.
> Just food for thought, it was a topic of conversation in #rhel today.
>
> -AdamM
>
> --
> http://maxamillion.googlepages.com
> ---------------------------------------------------------
> () ascii ribbon campaign - against html e-mail
> /\ www.asciiribbon.org - against proprietary attachments
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list
>
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
_______________________________________________
epel-devel-list mailing list
epel-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
3:28 p.m.
On Mon, Jan 11, 2010 at 2:35 PM, Adam Miller
<maxamillion(a)fedoraproject.org> wrote:
The reason I wanted to bring this up is that we say in our policy
that
we do not ship packages that are shipped by RedHat in RHEL. But this
being a subscription channel that is not extremely popular, do we want
to revise that policy to say that we don't ship packages that are not
in the base channel of desktop/workstation/server/ap as those are the
most common or do we want to stick to the current policy quite
strictly?
In what context was it brought up? I'm inclined to think that we just
go with Base/Virt/Clustering/ClusterStorage (the things you get with
AP). We already ship 389 in EPEL, which is the upstream for RHDS. I
don't really see nagios as being any different.
On another note, Nagios for monitoring HPC deployments? Seriously? :)
3:41 p.m.
On Mon, Jan 11, 2010 at 3:28 PM, Jon Stanley <jonstanley(a)gmail.com> wrote:
On Mon, Jan 11, 2010 at 2:35 PM, Adam Miller
<maxamillion(a)fedoraproject.org> wrote:
> The reason I wanted to bring this up is that we say in our policy that
> we do not ship packages that are shipped by RedHat in RHEL. But this
> being a subscription channel that is not extremely popular, do we want
> to revise that policy to say that we don't ship packages that are not
> in the base channel of desktop/workstation/server/ap as those are the
> most common or do we want to stick to the current policy quite
> strictly?
In what context was it brought up? I'm inclined to think that we just
go with Base/Virt/Clustering/ClusterStorage (the things you get with
AP). We already ship 389 in EPEL, which is the upstream for RHDS. I
don't really see nagios as being any different.
Honestly not sure, I came in half way through the conversation trying
to defend EPEL for not shipping (or should not be shipping) something
that RedHat does already.
On another note, Nagios for monitoring HPC deployments? Seriously? :)
Agreed, I'd go ganglia.
_______________________________________________
epel-devel-list mailing list
epel-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
-AdamM
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
5:03 p.m.
What channel is nagios shipped in? If it's part of RHX (or whatever
that's been renamed to recently) it was desired to be out of scope
originally. At the one of the last RH Summits (I am thinking Boston 2
years ago) we discussed RHX and working with ISVs on getting software
into EPEL rather than a separate shipping channel. We never really
decided on anything though.
I guess we need more discussion on the specifics of nagios, but I do
wonder if we could revise the policy to be things covered in an AP
subscription. Otherwise, it's makes the desirability of EPEL rather
low. If I am running Enterprise Linux but don't have a good method to
get systems management tools, programming libraries and authentication
services, I probably wouldn't use EPEL for very long. I'd switch to
something else.
EPEL was designed to pair with RHEL. EPEL + RHEL should roughly match
the Fedora package collection. If it's RHEL + EPEL + Extra Channel1 +
Extra Channel2, ..... that's a difficult sell. Some people see value
in support/subscription on layered products, and some do not.
stahnma
1:41 a.m.
On Mon, 2010-01-11 at 17:03 -0600, Michael Stahnke wrote:
EPEL was designed to pair with RHEL. EPEL + RHEL should roughly
match
the Fedora package collection. If it's RHEL + EPEL + Extra Channel1 +
Extra Channel2, ..... that's a difficult sell. Some people see value
in support/subscription on layered products, and some do not.
So how about a policy where EPEL keeps the version the same as the one
in ExtraChannel but with a lower release number? This way people not
subscribing to ExtraChannel will get the software and people who do
subscribe to the channel will get the version from Red Hat.
--
David Juran
Sr. Consultant
Red Hat
+358-504-146348
4:31 a.m.
On 12/01/2010 07:41, David Juran wrote:
On Mon, 2010-01-11 at 17:03 -0600, Michael Stahnke wrote:
> EPEL was designed to pair with RHEL. EPEL + RHEL should roughly match
> the Fedora package collection. If it's RHEL + EPEL + Extra Channel1 +
> Extra Channel2, ..... that's a difficult sell. Some people see value
> in support/subscription on layered products, and some do not.
>
So how about a policy where EPEL keeps the version the same as the one
in ExtraChannel but with a lower release number? This way people not
subscribing to ExtraChannel will get the software and people who do
subscribe to the channel will get the version from Red Hat.
In this case, the version of Nagios in the RHEL repo is a version 2
release and that's almost prehistoric and uses a different syntax for
its config files than the far more widely used V3. In EPEL I think we
have V3.0.6 and even that's getting pretty old as v3.2.0 is in rpmforge
and on the Nagios web site.
Be much easier if RH orphaned the V2 release in that repo.
--
Trevor Hemsley
Infrastructure Engineer
.................................................
* C A L Y P S O
* Brighton, UK
OFFICE +44 (0) 1273 666 350
FAX +44 (0) 1273 666 351
.................................................
www.calypso.com
This electronic-mail might contain confidential information intended
only for the use by the entity named. If the reader of this message is
not the intended recipient, the reader is hereby notified that any
dissemination, distribution or copying is strictly prohibited.
* P * /*/ Please consider the environment before printing this e-mail /*/
8:01 a.m.
Once upon a time, Trevor Hemsley <trevor.hemsley(a)codefarm.com> said:
In this case, the version of Nagios in the RHEL repo is a version 2
release and that's almost prehistoric and uses a different syntax for
its config files than the far more widely used V3. In EPEL I think we
have V3.0.6 and even that's getting pretty old as v3.2.0 is in rpmforge
and on the Nagios web site.
No, the EPEL-5 version of Nagios is also the really old 2.12.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
9:25 a.m.
All this discussion is great and I think everyone has had solid
concerns and good points but it still leaves the original question
unanswered.
Do we stick to our policy as is or do we want to make a revision?
-AdamM
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
9:34 a.m.
On Tue, Jan 12, 2010 at 9:25 AM, Adam Miller
<maxamillion(a)fedoraproject.org> wrote:
All this discussion is great and I think everyone has had solid
concerns and good points but it still leaves the original question
unanswered.
Do we stick to our policy as is or do we want to make a revision?
It seems to me looking in from the outside that you have already made
a revision to the policy by including 389, nagios, and possibly other
things. Might as well move on the figuring out what the real policy is
going to be and correctly documenting it.
John
9:36 a.m.
On Tue, Jan 12, 2010 at 9:34 AM, inode0 <inode0(a)gmail.com> wrote:
On Tue, Jan 12, 2010 at 9:25 AM, Adam Miller
<maxamillion(a)fedoraproject.org> wrote:
> All this discussion is great and I think everyone has had solid
> concerns and good points but it still leaves the original question
> unanswered.
>
> Do we stick to our policy as is or do we want to make a revision?
It seems to me looking in from the outside that you have already made
a revision to the policy by including 389, nagios, and possibly other
things. Might as well move on the figuring out what the real policy is
going to be and correctly documenting it.
<SNIP>
Well that's kind of my point, if we stick to the policy as it stands
then we need to pull the violating packages.
-AdamM
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
9:48 a.m.
>> Do we stick to our policy as is or do we want to make a
revision?
I propose a revision. I propose we don't step on anything in the AP
channels. Also, if we are having a collision problem with other Red
Hat provided layered channels, a bug could be filed and we could
attempt to resolve it by a lower package number or something. It's
not that I blatantly want to ignore other channels, it's that if we
exclude all of those products in EPEL, EPEL becomes less useful to the
enterprise customers it was aimed at.
>
> It seems to me looking in from the outside that you have already made
> a revision to the policy by including 389, nagios, and possibly other
> things. Might as well move on the figuring out what the real policy is
> going to be and correctly documenting it.
389 isn't a policy violation, Red Hat does not ship it. They ship Red
Hat DS, which is based from 389 but not the same thing. I would
assume we could ship spacewalk, freeipa and others in a similar
fashion.
stahnma
10:09 a.m.
On Tue, Jan 12, 2010 at 9:48 AM, Michael Stahnke <mastahnke(a)gmail.com> wrote:
>>> Do we stick to our policy as is or do we want to make a
revision?
I propose a revision. I propose we don't step on anything in the AP
channels. Also, if we are having a collision problem with other Red
Hat provided layered channels, a bug could be filed and we could
attempt to resolve it by a lower package number or something. It's
not that I blatantly want to ignore other channels, it's that if we
exclude all of those products in EPEL, EPEL becomes less useful to the
enterprise customers it was aimed at.
>> It seems to me looking in from the outside that you have already made
>> a revision to the policy by including 389, nagios, and possibly other
>> things. Might as well move on the figuring out what the real policy is
>> going to be and correctly documenting it.
389 isn't a policy violation, Red Hat does not ship it. They ship Red
Hat DS, which is based from 389 but not the same thing. I would
assume we could ship spacewalk, freeipa and others in a similar
fashion.
If it doesn't conflict with an installed RHDS it isn't a problem. I
see it as something of a problem if it does regardless of the policy.
I assume that all the 389 packages probably have different names so it
is likely safe but I don't know what else it might pull into the repo
if anything.
And given the fact that Red Hat is now naming packages delivered with
Satellite as spacewalk-* I'm not very confident that the wall between
what is upstream and what Red Hat provides is secure enough to avoid
conflicts in any of these products.
My understanding of EPEL's mission was that it would allow me to begin
with a RHEL + layered product box, configure EPEL, get additional
stuff without creating new problems. I think that is a wonderful
mission.
If this becomes I can begin with a box with anything I can get from
AP, configure EPEL, get additional stuff without creating new problems
I think we have a slightly less wonderful mission abstractly but
perhaps a more effective mission in the real world.
John
11 a.m.
On Tue, Jan 12, 2010 at 9:09 AM, inode0 <inode0(a)gmail.com> wrote:
On Tue, Jan 12, 2010 at 9:48 AM, Michael Stahnke
<mastahnke(a)gmail.com> wrote:
>>>> Do we stick to our policy as is or do we want to make a revision?
> I propose a revision. I propose we don't step on anything in the AP
> channels. Also, if we are having a collision problem with other Red
> Hat provided layered channels, a bug could be filed and we could
> attempt to resolve it by a lower package number or something. It's
> not that I blatantly want to ignore other channels, it's that if we
> exclude all of those products in EPEL, EPEL becomes less useful to the
> enterprise customers it was aimed at.
>
>>> It seems to me looking in from the outside that you have already made
>>> a revision to the policy by including 389, nagios, and possibly other
>>> things. Might as well move on the figuring out what the real policy is
>>> going to be and correctly documenting it.
>
> 389 isn't a policy violation, Red Hat does not ship it. They ship Red
> Hat DS, which is based from 389 but not the same thing. I would
> assume we could ship spacewalk, freeipa and others in a similar
> fashion.
If it doesn't conflict with an installed RHDS it isn't a problem. I
see it as something of a problem if it does regardless of the policy.
I assume that all the 389 packages probably have different names so it
is likely safe but I don't know what else it might pull into the repo
if anything.
And given the fact that Red Hat is now naming packages delivered with
Satellite as spacewalk-* I'm not very confident that the wall between
what is upstream and what Red Hat provides is secure enough to avoid
conflicts in any of these products.
My understanding of EPEL's mission was that it would allow me to begin
with a RHEL + layered product box, configure EPEL, get additional
stuff without creating new problems. I think that is a wonderful
mission.
If this becomes I can begin with a box with anything I can get from
AP, configure EPEL, get additional stuff without creating new problems
I think we have a slightly less wonderful mission abstractly but
perhaps a more effective mission in the real world.
Ok this is the problem with strict policies versus writing to intention:
If Red Hat were to mirror everything in EPEL as a channel called
"Unsupported Community Packages from EPEL" our logical conclusion
would be to remove all those packages from EPEL... which would remove
them from that channel, which means we could add packages back to EPEL
which would...
So what is the intention that we are wanting? And can we write to
that. Here is a list of things that come to mind in no meant order.
1) We do not wish to replace or conflict with the channels from a Base
install. [EG if its on the DVD RHEL provides we don't replace or
conflict.]
2) We do not know what is in all the other RHN channels. We do not
know what will be in an update either.
3) Red Hat people would like that their 'free' versions of packages
were in EPEL (the spacewalk people would like spacewalk, the 389
people would like 389, etc) as it allows them to push newer packages
to people who are testing them in real environments.
4) However inclusion of this will cause problems with other RH products.
So how should we word it to best work out intention, should we look at
our own layering of stuff, or something else... and whatever we decide
lets do it.. this seems like the 8th time this discussion has come up.
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
11:41 a.m.
On Tue, 2010-01-12 at 10:00 -0700, Stephen John Smoogen wrote:
<snip>
Ok this is the problem with strict policies versus writing to
intention:
If Red Hat were to mirror everything in EPEL as a channel called
"Unsupported Community Packages from EPEL" our logical conclusion
would be to remove all those packages from EPEL... which would remove
them from that channel, which means we could add packages back to EPEL
which would...
So what is the intention that we are wanting? And can we write to
that. Here is a list of things that come to mind in no meant order.
1) We do not wish to replace or conflict with the channels from a Base
install. [EG if its on the DVD RHEL provides we don't replace or
conflict.]
2) We do not know what is in all the other RHN channels. We do not
know what will be in an update either.
3) Red Hat people would like that their 'free' versions of packages
were in EPEL (the spacewalk people would like spacewalk, the 389
people would like 389, etc) as it allows them to push newer packages
to people who are testing them in real environments.
Possibly RH could use a one-higher Epoch in their channels. Everybody
wins.
4) However inclusion of this will cause problems with other RH
products.
So how should we word it to best work out intention, should we look at
our own layering of stuff, or something else... and whatever we decide
lets do it.. this seems like the 8th time this discussion has come up.
--
Christopher McCrory
"The guy that keeps the servers running"
chrismcc(a)pricegrabber.com
http://www.pricegrabber.com
Let's face it, there's no Hollow Earth, no robots, and
no 'mute rays.' And even if there were, waxed paper is
no defense. I tried it. Only tinfoil works.
7:41 a.m.
On Tue, Jan 12, 2010 at 09:41:00AM -0800, Christopher wrote:
Possibly RH could use a one-higher Epoch in their channels.
Everybody
wins.
That's the path of madness. Let's please not encourage it.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect
Cyberinfrastructure Labs / Instructional & Research Computing
Computing & Information Technology
Harvard School of Engineering & Applied Sciences
10:11 a.m.
On Wed, Jan 13, 2010 at 6:41 AM, Matthew Miller <mattdm(a)mattdm.org> wrote:
On Tue, Jan 12, 2010 at 09:41:00AM -0800, Christopher wrote:
> Possibly RH could use a one-higher Epoch in their channels. Everybody
> wins.
That's the path of madness. Let's please not encourage it.
We also checked and rpm doesn't allow us to use an EPOCH of -1 (for
even more madness).
I think in the end, we are going to either rebuild what they have in
that channel OR not ship it. Joy.
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
1:13 p.m.
On 01/13/2010 06:11 PM, Stephen John Smoogen wrote:
On Wed, Jan 13, 2010 at 6:41 AM, Matthew Miller
<mattdm(a)mattdm.org> wrote:
> On Tue, Jan 12, 2010 at 09:41:00AM -0800, Christopher wrote:
>
>> Possibly RH could use a one-higher Epoch in their channels. Everybody
>> wins.
>>
> That's the path of madness. Let's please not encourage it.
>
>
We also checked and rpm doesn't allow us to use an EPOCH of -1 (for
even more madness).
I think in the end, we are going to either rebuild what they have in
that channel OR not ship it. Joy.
or recommend using yum-priorities and use priority=1 for base / updates
/ RHN and >=2 for EPEL.
1:50 p.m.
On Wed, Jan 13, 2010 at 1:13 PM, Manuel Wolfshant
<wolfy(a)nobugconsulting.ro> wrote:
or recommend using yum-priorities and use priority=1 for base /
updates /
RHN and >=2 for EPEL.
I don't believe yum-priorities works with yum-rhn-plugin nor is it
available on RHN or in EPEL and I know it isn't going to work
pre-RHEL5.
John
2:12 p.m.
On 01/13/2010 09:50 PM, inode0 wrote:
On Wed, Jan 13, 2010 at 1:13 PM, Manuel Wolfshant
<wolfy(a)nobugconsulting.ro> wrote:
> or recommend using yum-priorities and use priority=1 for base / updates /
> RHN and >=2 for EPEL.
>
I don't believe yum-priorities works with yum-rhn-plugin nor is it
available on RHN or in EPEL and I know it isn't going to work
pre-RHEL5.
The extras repository from Centos 4 carries both
yum-plugin-priorities-0.0.7-2.c4.noarch.rpm and
yum-plugin-protectbase-1.1-1.c4.noarch.rpm and they work just fine.
2:19 p.m.
On Wed, Jan 13, 2010 at 2:12 PM, Manuel Wolfshant
<wolfy(a)nobugconsulting.ro> wrote:
On 01/13/2010 09:50 PM, inode0 wrote:
>
> On Wed, Jan 13, 2010 at 1:13 PM, Manuel Wolfshant
> <wolfy(a)nobugconsulting.ro> wrote:
>
>>
>> or recommend using yum-priorities and use priority=1 for base / updates /
>> RHN and >=2 for EPEL.
>>
>
> I don't believe yum-priorities works with yum-rhn-plugin nor is it
> available on RHN or in EPEL and I know it isn't going to work
> pre-RHEL5.
>
>
The extras repository from Centos 4 carries both
yum-plugin-priorities-0.0.7-2.c4.noarch.rpm and
yum-plugin-protectbase-1.1-1.c4.noarch.rpm and they work just fine.
CentOS doesn't use RHN. Have you tested any this against RHN?
John
5:28 p.m.
Hello...
On Wed, 2010-01-13 at 21:13 +0200, Manuel Wolfshant wrote:
On 01/13/2010 06:11 PM, Stephen John Smoogen wrote:
> On Wed, Jan 13, 2010 at 6:41 AM, Matthew Miller <mattdm(a)mattdm.org> wrote:
>
>> On Tue, Jan 12, 2010 at 09:41:00AM -0800, Christopher wrote:
>>
>>> Possibly RH could use a one-higher Epoch in their channels. Everybody
>>> wins.
>>>
>> That's the path of madness. Let's please not encourage it.
>>
>>
>
> We also checked and rpm doesn't allow us to use an EPOCH of -1 (for
> even more madness).
>
> I think in the end, we are going to either rebuild what they have in
> that channel OR not ship it. Joy.
>
>
or recommend using yum-priorities and use priority=1 for base / updates
/ RHN and >=2 for EPEL.
cost works in default RHEL5
from man yum.conf
cost relative cost of accessing this repository. Useful for
weighing one repo's packages as greater/less than any other.
defaults to 1000
/etc/yum.repos.d/epel.repo could contain cost=1001
yes? no? maybe?
I use cost=100 so my local repo always wins against rhn
_______________________________________________
epel-devel-list mailing list
epel-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
--
Christopher McCrory
"The guy that keeps the servers running"
chrismcc(a)pricegrabber.com
http://www.pricegrabber.com
Let's face it, there's no Hollow Earth, no robots, and
no 'mute rays.' And even if there were, waxed paper is
no defense. I tried it. Only tinfoil works.
5:54 p.m.
On Wed, Jan 13, 2010 at 5:28 PM, Christopher <chrismcc(a)pricegrabber.com> wrote:
cost works in default RHEL5
from man yum.conf
cost relative cost of accessing this repository. Useful for
weighing one repo's packages as greater/less than any other.
defaults to 1000
/etc/yum.repos.d/epel.repo could contain cost=1001
yes? no? maybe?
I use cost=100 so my local repo always wins against rhn
Does it really work? I honestly don't know but being in the yum docs
isn't persuasive evidence that it will work against RHN channels which
are not ordinary yum repositories. The yum-rhn-plugin has to support
it for it to work with RHN and until very recently it supported pretty
much nothing. I believe in 5.3 or thereabouts yum-rhn-plugin first
allowed the ability to even specify enabled/disabled for individual
RHN channels.
With RHEL5 people can always use includepkgs with EPEL so there does
in fact exist a way to mitigate conflicts but ...
All these yum-based suggestions though leave me scratching my head a
little. Let's stipulate for argument's sake that some yum dance would
give us a way to work around conflicts. If I need to worry about
conflicts and set up this or that to avoid them or mitigate danger,
then I feel like I've lost one of the key selling features of EPEL. I
do those dances for rpmforge, EPEL was supposed to make my life
easier.
So I think the question just fundamentally comes down to do we want to
avoid conflicts or do we want a really large and useful package set
more. Good arguments can be made for both directions and both
directions come with a price. Not an easy choice to make. Can we have
our cake and eat it too with multiple EPEL repos? One for conflicts
and one guaranteed to be free of conflicts? With a price we can but
can we pay that price?
John
12:02 p.m.
Hello...
On Wed, 2010-01-13 at 17:54 -0600, inode0 wrote:
On Wed, Jan 13, 2010 at 5:28 PM, Christopher
<chrismcc(a)pricegrabber.com> wrote:
> cost works in default RHEL5
>
> from man yum.conf
>
> cost relative cost of accessing this repository. Useful for
> weighing one repo's packages as greater/less than any other.
> defaults to 1000
>
> /etc/yum.repos.d/epel.repo could contain cost=1001
>
> yes? no? maybe?
>
> I use cost=100 so my local repo always wins against rhn
Does it really work? I honestly don't know but being in the yum docs
isn't persuasive evidence that it will work against RHN channels which
are not ordinary yum repositories. The yum-rhn-plugin has to support
it for it to work with RHN and until very recently it supported pretty
much nothing. I believe in 5.3 or thereabouts yum-rhn-plugin first
allowed the ability to even specify enabled/disabled for individual
RHN channels.
It works in RHEL 5.4, I cannot test other versions.
With RHEL5 people can always use includepkgs with EPEL so there does
in fact exist a way to mitigate conflicts but ...
All these yum-based suggestions though leave me scratching my head a
little. Let's stipulate for argument's sake that some yum dance would
give us a way to work around conflicts. If I need to worry about
conflicts and set up this or that to avoid them or mitigate danger,
then I feel like I've lost one of the key selling features of EPEL. I
do those dances for rpmforge, EPEL was supposed to make my life
easier.
Agreed.
So I think the question just fundamentally comes down to do we want
to
avoid conflicts or do we want a really large and useful package set
more. Good arguments can be made for both directions and both
directions come with a price. Not an easy choice to make. Can we have
our cake and eat it too with multiple EPEL repos? One for conflicts
and one guaranteed to be free of conflicts? With a price we can but
can we pay that price?
John
<with other messages in this thread considered>
What about something like;
EPEL MUST NOT conflict with the main RHEL base.
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Client/en/os/
EPEL SHOULD NOT conflict with anything in the RH add-on products, as
considered on a case by case basis.
A specific example. Red Hat Enterprise MRG, http://www.redhat.com/mrg/,
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/RHEMRG/SRPMS . EPEL should
not also offer any of the core packages in that product. But puppet/facter are in EPEL,
and AFAICT were in EPEL before MRG was a product. puppet/facter are not the core product,
but help to configure the core product. In this case EPEL should work with RH so that
both repos can contain puppet/facter. This could be RH using an Epoch+1, EPEL using a
higher cost, RH testing MRG with puppet from EPEL, or some other solution.
So, IMHO, the EPEL policy should be something like "We don't want to
trump RedHat's products"
--
Christopher McCrory
"The guy that keeps the servers running"
chrismcc(a)pricegrabber.com
http://www.pricegrabber.com
Let's face it, there's no Hollow Earth, no robots, and
no 'mute rays.' And even if there were, waxed paper is
no defense. I tried it. Only tinfoil works.
2:11 a.m.
On Wed, 2010-01-13 at 21:13 +0200, Manuel Wolfshant wrote:
On 01/13/2010 06:11 PM, Stephen John Smoogen wrote:
> On Wed, Jan 13, 2010 at 6:41 AM, Matthew Miller <mattdm(a)mattdm.org> wrote:
>
>> On Tue, Jan 12, 2010 at 09:41:00AM -0800, Christopher wrote:
>>
>>> Possibly RH could use a one-higher Epoch in their channels. Everybody
>>> wins.
>>>
>> That's the path of madness. Let's please not encourage it.
>>
>>
>
> We also checked and rpm doesn't allow us to use an EPOCH of -1 (for
> even more madness).
>
> I think in the end, we are going to either rebuild what they have in
> that channel OR not ship it. Joy.
+1
or recommend using yum-priorities and use priority=1 for base /
updates
/ RHN and >=2 for EPEL.
In addition to what everyone else already mentioned, this will cause a
problem if someone first installs a version from EPEL and then
subscribes to the Red Hat Channel. If the version in EPEL then is
higher, the package will be "orphaned".
--
David Juran
Sr. Consultant
Red Hat
+358-504-146348
2:41 p.m.
On Tue, Jan 12, 2010 at 9:09 AM, inode0 <inode0(a)gmail.com> wrote:
On Tue, Jan 12, 2010 at 9:48 AM, Michael Stahnke
<mastahnke(a)gmail.com> wrote:
My understanding of EPEL's mission was that it would allow me to
begin
with a RHEL + layered product box, configure EPEL, get additional
stuff without creating new problems. I think that is a wonderful
mission.
I think that was one vision. The issue is that it is almost
impossible in practicality to accomplish. Especially when some RH
channels replace stuff that is in core (MRTG). It makes the job of
EPEL a lot more of reacting to unknown forces and also makes it hard
when say we have been putting cobbler or puppet in and then a previous
version shows up on RHN. We can remove our version but its not going
to fix the person who has the newer version and then never gets
updates to what is in RHN.
I will be making a list of all these sub-packages today.. will see
what would need to be removed.
If this becomes I can begin with a box with anything I can get from
AP, configure EPEL, get additional stuff without creating new problems
I think we have a slightly less wonderful mission abstractly but
perhaps a more effective mission in the real world.
John
_______________________________________________
epel-devel-list mailing list
epel-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
12:17 p.m.
On Tue, Jan 12, 2010 at 4:48 PM, Michael Stahnke <mastahnke(a)gmail.com> wrote:
>>> Do we stick to our policy as is or do we want to make a
revision?
Just to check these extra channels with nagios in for instance are not available
from CentOS or similar are they? Moving to an expected base below EPEL that
is bigger than CentOS will surly create a problem for many people.
I propose a revision. I propose we don't step on anything in the
AP
channels. Also, if we are having a collision problem with other Red
Hat provided layered channels, a bug could be filed and we could
attempt to resolve it by a lower package number or something. It's
not that I blatantly want to ignore other channels, it's that if we
exclude all of those products in EPEL, EPEL becomes less useful to the
enterprise customers it was aimed at.
>>
>> It seems to me looking in from the outside that you have already made
>> a revision to the policy by including 389, nagios, and possibly other
>> things. Might as well move on the figuring out what the real policy is
>> going to be and correctly documenting it.
389 isn't a policy violation, Red Hat does not ship it. They ship Red
Hat DS, which is based from 389 but not the same thing. I would
assume we could ship spacewalk, freeipa and others in a similar
fashion.
stahnma
_______________________________________________
epel-devel-list mailing list
epel-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
--
Steve Traylen
1:49 p.m.
On Tue, Jan 12, 2010 at 11:17 AM, Steve Traylen <steve.traylen(a)cern.ch> wrote:
On Tue, Jan 12, 2010 at 4:48 PM, Michael Stahnke
<mastahnke(a)gmail.com> wrote:
>>>> Do we stick to our policy as is or do we want to make a revision?
Just to check these extra channels with nagios in for instance are not available
from CentOS or similar are they? Moving to an expected base below EPEL that
is bigger than CentOS will surly create a problem for many people.
No they are not available in the base channels of CentOS. To be
honest, I think those are the 'channels' we should stick to for
checking what is in or not in EPEL. It leads to other logic loops but
for the most part we can agree that is a good base to look at.
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
2:20 p.m.
Here's a proposal:
Let's make an alteration to our current policy to something of the
effect that "we do not ship any package that has an openly available
RPM/SRPM located in any child directory of
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ but we are unable to
verify that there will be no conflicts as not all channels are
published."
Beyond that I don't think there is any realistic expectation of us to
know what we could potentially conflict with if the information is not
publicly available.
-AdamM
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
2:27 p.m.
On Tue, Jan 12, 2010 at 1:20 PM, Adam Miller
<maxamillion(a)fedoraproject.org> wrote:
Here's a proposal:
Let's make an alteration to our current policy to something of the
effect that "we do not ship any package that has an openly available
RPM/SRPM located in any child directory of
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ but we are unable to
verify that there will be no conflicts as not all channels are
published."
Beyond that I don't think there is any realistic expectation of us to
know what we could potentially conflict with if the information is not
publicly available.
-AdamM
"EPEL is purely a complimentary add-on repository and does not replace
packages in RHEL or layered products."
to
"EPEL is purely a complimentary add-on repository and does not replace
packages in RHEL. [Package conflicts are determined by what is openly
available from Red Hat's tree (currently located at
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/) ]
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
_______________________________________________
epel-devel-list mailing list
epel-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
2:30 p.m.
On Tue, Jan 12, 2010 at 2:27 PM, Stephen John Smoogen <smooge(a)gmail.com> wrote:
On Tue, Jan 12, 2010 at 1:20 PM, Adam Miller
<maxamillion(a)fedoraproject.org> wrote:
> Here's a proposal:
>
> Let's make an alteration to our current policy to something of the
> effect that "we do not ship any package that has an openly available
> RPM/SRPM located in any child directory of
> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ but we are unable to
> verify that there will be no conflicts as not all channels are
> published."
>
> Beyond that I don't think there is any realistic expectation of us to
> know what we could potentially conflict with if the information is not
> publicly available.
>
> -AdamM
"EPEL is purely a complimentary add-on repository and does not replace
packages in RHEL or layered products."
to
"EPEL is purely a complimentary add-on repository and does not replace
packages in RHEL. [Package conflicts are determined by what is openly
available from Red Hat's tree (currently located at
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/) ]
<SNIP>
I like it, +1 here. Should we put this to a vote at the next meeting
or do we want to take a poll here on the mailing list?
-AdamM
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
2:34 p.m.
On Tue, Jan 12, 2010 at 1:30 PM, Adam Miller
<maxamillion(a)fedoraproject.org> wrote:
On Tue, Jan 12, 2010 at 2:27 PM, Stephen John Smoogen
<smooge(a)gmail.com> wrote:
> On Tue, Jan 12, 2010 at 1:20 PM, Adam Miller
> <maxamillion(a)fedoraproject.org> wrote:
>> Here's a proposal:
>>
>> Let's make an alteration to our current policy to something of the
>> effect that "we do not ship any package that has an openly available
>> RPM/SRPM located in any child directory of
>> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ but we are unable to
>> verify that there will be no conflicts as not all channels are
>> published."
>>
>> Beyond that I don't think there is any realistic expectation of us to
>> know what we could potentially conflict with if the information is not
>> publicly available.
>>
>> -AdamM
>
> "EPEL is purely a complimentary add-on repository and does not replace
> packages in RHEL or layered products."
>
> to
>
> "EPEL is purely a complimentary add-on repository and does not replace
> packages in RHEL. [Package conflicts are determined by what is openly
> available from Red Hat's tree (currently located at
> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/) ]
>
<SNIP>
I like it, +1 here. Should we put this to a vote at the next meeting
or do we want to take a poll here on the mailing list?
-AdamM
We should take a poll on the list and finalize on Friday meeting.
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
5:24 a.m.
On Tue, Jan 12, 2010 at 01:34:34PM -0700, Stephen John Smoogen wrote:
On Tue, Jan 12, 2010 at 1:30 PM, Adam Miller
<maxamillion(a)fedoraproject.org> wrote:
> On Tue, Jan 12, 2010 at 2:27 PM, Stephen John Smoogen <smooge(a)gmail.com>
wrote:
>> On Tue, Jan 12, 2010 at 1:20 PM, Adam Miller
>> <maxamillion(a)fedoraproject.org> wrote:
>> "EPEL is purely a complimentary add-on repository and
does not replace
>> packages in RHEL or layered products."
>>
>> to
>>
>> "EPEL is purely a complimentary add-on repository and does not replace
>> packages in RHEL. [Package conflicts are determined by what is openly
>> available from Red Hat's tree (currently located at
>> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/) ]
>>
> <SNIP>
>
> I like it, +1 here. Should we put this to a vote at the next meeting
> or do we want to take a poll here on the mailing list?
>
> -AdamM
>
We should take a poll on the list and finalize on Friday meeting.
Imho before there is a decision, the consequences of it should be
explained to people who do not use RHEL. Which packages will this make
remove from EPEL? Afaics, there are 13 repositories involved to find
conflicts, therefore someone who really uses RHEL can probably create a
list of affected packages a lot easier, compare it with EPEL and show
which packages would be removed. This has to be done anyhow if the new
policy is accepted, otherwise you cannot enforce it, so better do it
before the change.
Regards
Till
4:21 p.m.
On Tue, Jan 12, 2010 at 2:27 PM, Stephen John Smoogen <smooge(a)gmail.com> wrote:
"EPEL is purely a complimentary add-on repository and does not
replace
packages in RHEL or layered products."
to
"EPEL is purely a complimentary add-on repository and does not replace
packages in RHEL. [Package conflicts are determined by what is openly
available from Red Hat's tree (currently located at
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/) ]
I would appreciate you putting up with one more serious question from
the perspective of a user. Since RHEIPA, RHSAT, RHDirServ, RHCERT,
RHWAS, and more fall into this new category and since the upstream
versions of many of those have been suggested as desirable targets for
inclusion in EPEL can you help me understand what a package conflict
means in this case? Is it a conflict at the package level? Is it a
conflict at the file level?
John
4:44 p.m.
On Tue, Jan 12, 2010 at 3:21 PM, inode0 <inode0(a)gmail.com> wrote:
On Tue, Jan 12, 2010 at 2:27 PM, Stephen John Smoogen
<smooge(a)gmail.com> wrote:
> "EPEL is purely a complimentary add-on repository and does not replace
> packages in RHEL or layered products."
>
> to
>
> "EPEL is purely a complimentary add-on repository and does not replace
> packages in RHEL. [Package conflicts are determined by what is openly
> available from Red Hat's tree (currently located at
> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/) ]
I would appreciate you putting up with one more serious question from
the perspective of a user. Since RHEIPA, RHSAT, RHDirServ, RHCERT,
RHWAS, and more fall into this new category and since the upstream
versions of many of those have been suggested as desirable targets for
inclusion in EPEL can you help me understand what a package conflict
means in this case? Is it a conflict at the package level? Is it a
conflict at the file level?
I am not sure what you mean fall into this new category. None of the
channels listed above seem to be in
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ [Nor are some of
them on ftp://ftp.redhat.com/ in a form that could be used to build
file/package conflicts from.]
Could you define it a bit better for me?
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
6:08 p.m.
On Tue, Jan 12, 2010 at 4:44 PM, Stephen John Smoogen <smooge(a)gmail.com> wrote:
On Tue, Jan 12, 2010 at 3:21 PM, inode0 <inode0(a)gmail.com>
wrote:
> On Tue, Jan 12, 2010 at 2:27 PM, Stephen John Smoogen <smooge(a)gmail.com>
wrote:
>> "EPEL is purely a complimentary add-on repository and does not replace
>> packages in RHEL or layered products."
>>
>> to
>>
>> "EPEL is purely a complimentary add-on repository and does not replace
>> packages in RHEL. [Package conflicts are determined by what is openly
>> available from Red Hat's tree (currently located at
>> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/) ]
>
> I would appreciate you putting up with one more serious question from
> the perspective of a user. Since RHEIPA, RHSAT, RHDirServ, RHCERT,
> RHWAS, and more fall into this new category and since the upstream
> versions of many of those have been suggested as desirable targets for
> inclusion in EPEL can you help me understand what a package conflict
> means in this case? Is it a conflict at the package level? Is it a
> conflict at the file level?
I am not sure what you mean fall into this new category. None of the
channels listed above seem to be in
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ [Nor are some of
them on ftp://ftp.redhat.com/ in a form that could be used to build
file/package conflicts from.]
Could you define it a bit better for me?
You need to drill down a bit to see them.
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/
John
7:32 p.m.
On Tue, Jan 12, 2010 at 5:08 PM, inode0 <inode0(a)gmail.com> wrote:
On Tue, Jan 12, 2010 at 4:44 PM, Stephen John Smoogen
<smooge(a)gmail.com> wrote:
> On Tue, Jan 12, 2010 at 3:21 PM, inode0 <inode0(a)gmail.com> wrote:
>> On Tue, Jan 12, 2010 at 2:27 PM, Stephen John Smoogen <smooge(a)gmail.com>
wrote:
>>> "EPEL is purely a complimentary add-on repository and does not replace
>>> packages in RHEL or layered products."
>>>
>>> to
>>>
>>> "EPEL is purely a complimentary add-on repository and does not replace
>>> packages in RHEL. [Package conflicts are determined by what is openly
>>> available from Red Hat's tree (currently located at
>>> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/) ]
>>
>> I would appreciate you putting up with one more serious question from
>> the perspective of a user. Since RHEIPA, RHSAT, RHDirServ, RHCERT,
>> RHWAS, and more fall into this new category and since the upstream
>> versions of many of those have been suggested as desirable targets for
>> inclusion in EPEL can you help me understand what a package conflict
>> means in this case? Is it a conflict at the package level? Is it a
>> conflict at the file level?
>
> I am not sure what you mean fall into this new category. None of the
> channels listed above seem to be in
> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ [Nor are some of
> them on ftp://ftp.redhat.com/ in a form that could be used to build
> file/package conflicts from.]
>
> Could you define it a bit better for me?
You need to drill down a bit to see them.
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/
Well how the henry did I miss them when I did a find earlier.. they
are there.. but I didnt see them. hmmm time to think about this a bit
more.
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
7:38 p.m.
On Tue, 12 Jan 2010, inode0 wrote:
On Tue, Jan 12, 2010 at 2:27 PM, Stephen John Smoogen
<smooge(a)gmail.com> wrote:
> "EPEL is purely a complimentary add-on repository and does not replace
> packages in RHEL or layered products."
>
> to
>
> "EPEL is purely a complimentary add-on repository and does not replace
> packages in RHEL. [Package conflicts are determined by what is openly
> available from Red Hat's tree (currently located at
> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/) ]
I would appreciate you putting up with one more serious question from
the perspective of a user. Since RHEIPA, RHSAT, RHDirServ, RHCERT,
RHWAS, and more fall into this new category and since the upstream
versions of many of those have been suggested as desirable targets for
inclusion in EPEL can you help me understand what a package conflict
means in this case? Is it a conflict at the package level? Is it a
conflict at the file level?
I'm conflicted about this for a lot of reasons. First, I'm the nagios
packager (though orphaning if anyone wants it. I've been meaning to for a
while but have been too lazy)
The second concern is that other packages fall into this category. For my
job in Fedora, Turbogears is a big deal. Right now the people that
package TurboGears actually work with me in Fedora Infrasturcture. So
when we have a problem, it magically goes away.
At the same time though. The point of EPEL from the start as I understood
it is we don't replace packages in RHEL and we don't allow EPEL to be a
way to route around or not pay for channels (which is why we don't ship
the cluster suite). The whole deal was to provide not just extra packages
for enterprise linux but also peace of mind for people that use RHEL.
This is a tough position to be in, it really is. I'm going to think on it
some but I'm more inclined to say if RH ships it we remove it from EPEL
even though I'm 95% sure that's going to make my life in Fedora
Infrastructure harder.
/me goes to think some more.
-Mike
3:26 a.m.
On 12/01/10 20:27, Stephen John Smoogen wrote:
On Tue, Jan 12, 2010 at 1:20 PM, Adam Miller
<maxamillion(a)fedoraproject.org> wrote:
> Here's a proposal:
>
> Let's make an alteration to our current policy to something of the
> effect that "we do not ship any package that has an openly available
> RPM/SRPM located in any child directory of
> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ but we are unable to
> verify that there will be no conflicts as not all channels are
> published."
>
> Beyond that I don't think there is any realistic expectation of us to
> know what we could potentially conflict with if the information is not
> publicly available.
>
> -AdamM
"EPEL is purely a complimentary add-on repository and does not replace
packages in RHEL or layered products."
to
"EPEL is purely a complimentary add-on repository and does not replace
packages in RHEL. [Package conflicts are determined by what is openly
available from Red Hat's tree (currently located at
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/) ]
s/complimentary/complementary/
Paul.
7:21 p.m.
On Tue, Jan 12, 2010 at 02:20:35PM -0600, Adam Miller wrote:
Here's a proposal:
Let's make an alteration to our current policy to something of the
effect that "we do not ship any package that has an openly available
RPM/SRPM located in any child directory of
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ but we are unable to
verify that there will be no conflicts as not all channels are
published."
With a quick look I see puppet, facter, ruby-shadow, jfreechart,
python-cheetah, python-simplejson, cobbler, perl-GD, TurboGears,
python-kerberos available there...
Kostas Georgiou
7:31 p.m.
On Tue, Jan 12, 2010 at 6:21 PM, Kostas Georgiou
<k.georgiou(a)imperial.ac.uk> wrote:
On Tue, Jan 12, 2010 at 02:20:35PM -0600, Adam Miller wrote:
> Here's a proposal:
>
> Let's make an alteration to our current policy to something of the
> effect that "we do not ship any package that has an openly available
> RPM/SRPM located in any child directory of
> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ but we are unable to
> verify that there will be no conflicts as not all channels are
> published."
With a quick look I see puppet, facter, ruby-shadow, jfreechart,
python-cheetah, python-simplejson, cobbler, perl-GD, TurboGears,
python-kerberos available there...
Well put butter on me and call me a bisquit. That pretty much says
'screw me'.. well on the other hand... it makes EPEL much smaller to
deal with :). Ok let me think this over a bit more and figure out a
better wording.
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
5213
days inactive
5216
days old
epel-devel@lists.fedoraproject.org
44 comments
16 participants
participants (16)
-
Adam Miller -
Chris Adams -
Christopher McCrory -
David Juran -
inode0 -
Jon Stanley -
Kostas Georgiou -
Manuel Wolfshant -
Matthew Miller -
Michael Stahnke -
Mike McGrath -
Paul Howarth -
Stephen John Smoogen -
Steve Traylen -
Till Maas -
Trevor Hemsley