On Fri, Jun 15, 2012 at 12:34 PM, Kevin Fenzi kevin@scrye.com wrote:

On Fri, 15 Jun 2012 12:27:30 -0500 inode0 inode0@gmail.com wrote:

...

On Fri, Jun 15, 2012 at 11:43 AM, Kevin Fenzi kevin@scrye.com wrote:

...

Ok, here's another attempt at an overlap policy.

I'd like to ask folks to comment on it again, but please... I'm a technical person. I like technical arguments. If you don't like this policy, please propose an alternate one you like better and tell us why. Or if you like this policy ok, but changing some wording would make it much more acceptable, tell us that.

ok? Here's another stab at it:

"EPEL6 will not normally ship packages that are shipped already in the following RHEL channels: os, optional, lb, and ha. Any overlapping packages must be to provide binary packages on arches not provided by RHEL ( following: http://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages ). Additional channels may be added to this list, based on a criteria the EPEL sig has yet to decide on."

I'm sorry if this has been answered before and I have forgotten the answer but why are the lb and ha bits excluded? Was there a request from the RHEL side to exclude them?

They were added to our buildsystem a while back because they contained dependencies that were used by epel packages. There wasn't a formal request that I know of, but it was requested by several maintainers.

I suppose we could look at dropping them.

No, I don't want them dropped from the build system. I want to know why piranha can't be packaged by EPEL for example?

I'm not sure which epel packages that would affect off hand, but can find out.

...

I'll let you folks go do your thing again without more interference from me but the inconsistent treatment of these two channels bothers me, in part because I'd like to see things from those channels more than from other Add-On channels. :)

You would like to see them in epel? or would like to see them not in epel since you use those channels and don't want conflicts?

If EPEL can ship rpms from the resilient storage channel I see no reason not to ship packages from the load balancer channel.

So the build system is os+optional+lb+ha+rs+other stuff I don't recall if I understood previously but EPEL only prohibits shipping packages from os+optional+lb+ha. I'm wondering why the restriction against shipping packages isn't just os+optional here.

John

On Fri, Jun 15, 2012 at 1:41 PM, Orion Poplawski orion@cora.nwra.com wrote:

On 06/15/2012 11:43 AM, inode0 wrote:

...

On Fri, Jun 15, 2012 at 12:34 PM, Kevin Fenzi kevin@scrye.com wrote:

...

On Fri, 15 Jun 2012 12:27:30 -0500 inode0 inode0@gmail.com wrote:

...

I'm sorry if this has been answered before and I have forgotten the answer but why are the lb and ha bits excluded? Was there a request from the RHEL side to exclude them?

They were added to our buildsystem a while back because they contained dependencies that were used by epel packages. There wasn't a formal request that I know of, but it was requested by several maintainers.

I suppose we could look at dropping them.

No, I don't want them dropped from the build system. I want to know why piranha can't be packaged by EPEL for example?

Well, piranha is shipped by ScientificLinux (and probably CentOS), presumably because the srpm is in 6Server, so you would end up with conflicts there.  If you are a paying RedHat customer and want support, presumably you would purchase the relevant channel as well to get piranha?

Oh, I missed the EPEL does not conflict with packages shipped by CentOS rule?!

Some paying RHEL customers use the two packages for LB from CentOS now and would rather use them from EPEL. This is not a logical reason to treat lb and ha differently from anything else CentOS might ship. Not to mention RHEL users who get puppet from EPEL when they could pay Red Hat for that too. My problem is mostly just that this seems completely arbitrary to me.

John

On Fri, Jun 15, 2012 at 2:06 PM, Stephen John Smoogen smooge@gmail.com wrote:

Well of course it is arbitrary. Any definition we use is going to be arbitrary because well there is no rock solid proof that says "this is RHEL" and "this isn't RHEL". Expecting us to define that definition when it is clear that even Red Hat has no rock solid definition is preposterous. So this is our arbitrary line in the sand. It is no better or worse than if we drew it 2 feet to the left or 2 feet to the right. However until the tide comes in and washes it away, this is the one we are looking to use.

True but drawing it two feet to the left treats all the fuzz consistently. If you are in the Add-Ons your package might be included in EPEL is much easier to remember and to understand than if you are in the Add-Ons but you aren't in the LB or the HA Add-Ons then your package might be included in EPEL.

Consistent, easy to grok as an EPEL/RHEL user, and more flexible for EPEL packagers.

John

On Fri, Jun 15, 2012 at 04:11:16PM -0400, Bryan J Smith wrote:

Stephen John Smoogen smooge@gmail.com wrote:

...

Expecting us to define that definition when it is clear that even Red Hat has no rock solid definition is preposterous.

Red Hat has _always_ had a rock solid definition of AS/AP. Even today, the version 6 entitlements map to AS/AP. There's no reason to end those, not after 10 years of lineage. But some want to. And some have stated their reasons. And I have pointed them out.

Back this up.

If you can list for us what actual channels are the equivalent of the old AS/AP then we have something else that we can try to use to define logically which channels should not be overlapped with. If you've found this information somewhere then giving it to us will be a valuable addition to the conversation. Otherwise, we'll have to continue to assume that there isn't an actual understanding of what that is and we'll have to continue to try to define it ourselves with a somewhat arbitrary division.

But in the process, you have to realize who is being considered the least.

At the moment, you are :-) You need to present less case studies and more facts. You're criticizing the ongoing effort to fix this without critiquing it. You're not adding constructive information that can help us to make a better division; only adding impossible or vague demands of what the solution should look like.

We're far more worried about giving the least subsidizing Red Hat customers everything they need, instead of also considering how much that will conflict with Red Hat's biggest, subsidizing customers.

Your "we" must mainly just be you ;-). It's certainly not me or, from my reading of their thoughts, smooge or nirik or inode0. (And if the smiley doesn't reflect it, I know that the "we" you used above was actually misuse of the first person plural. From your previous posts it seems apparent that you actually meant the second person plural there.)

-Toshio

Anyone with a RHN Satellite Server can do the entite media history from the Kickstartable Trees in 5 minutes. I.e., I've done it many times over the years, even recently off-list to many.

What I've heard is that some here will only accept a specific, actual statement from Red Hat on its own entitlement history. So doing such, which I've also done, is moot. I.e., we continue to have a lot of interpretation. On Jun 23, 2012 12:30 PM, "inode0" inode0@gmail.com wrote:

On Fri, Jun 15, 2012 at 5:14 PM, Toshio Kuratomi a.badger@gmail.com wrote:

...

If you can list for us what actual channels are the equivalent of the old AS/AP then we have something else that we can try to use to define

logically

...

which channels should not be overlapped with. If you've found this information somewhere then giving it to us will be a valuable addition to the conversation. Otherwise, we'll have to continue to assume that there isn't an actual understanding of what that is and we'll have to continue

to

...

try to define it ourselves with a somewhat arbitrary division.

I am willing to do some work here to attempt to sort this out since I think having a clear policy that EPEL users understand is worth the bother. I have media going back to RHEL3 and can sort through what came on it, which I think is a fair definition of what is part of "RHEL" proper prior to the release of RHEL6.

I do want to observe that there was a media change in RHEL5 which added some things to the media which required entitlements that go beyond a RHEL server subscription so there is a transition point of sorts at RHEL5. At a glance I'm guessing this added several items which include clustering and GFS, load balancing, and some virtualization bits.

Another observation that is important is that "comes on the installation media" doesn't cut it any more with the release of RHEL6 since half of RHEL6 isn't distributed on media due to its size growing so dramatically but simply adding the optional channel to what RHEL6 media contains seems to me to include what previously would have been distributed via the media with the possible exception of some or all of the Add-On channels which also may have been included on RHEL5 media.

So one question I have is whether it is worth the effort to go back beyond RHEL5 when looking at this now? Since Red Hat changes this up every release I doubt EPEL should be bound forever by whatever Red Hat did in 2004. Where do we want to draw the baseline now?

John

---

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

On Sat, Jun 23, 2012 at 1:01 PM, inode0 inode0@gmail.com wrote:

... based on some logic we have access to replicate are part of what you define to be RHEL that would be excellent ...

What I and others define with my customers as RHEL has been repeated viewed by many as unacceptable and/or non-authoritative. I.e., it's why I stated prior ...

"What I've heard is that some here will only accept a specific, actual statement from Red Hat on its own entitlement history. So doing such, which I've also done, is moot. I.e., we continue to have a lot of interpretation."

That drove why I said I've not only done it (many times in the past, and most recently last week), but any effort won't be accepted, because it's not from Red Hat, and not specifically laid out as people want it on a public page.

It also re-affirmed why I only post technical specifics off-list to select people. This is not only because my work would be trashed on-list (some has been trashed enough off-list), but a few people may make it ... oh how can I say this ... "difficult."

E.g., several people have me utterly confused for others inside of Red Hat, who I am not. I also don't want anything I say to be taken as policy, and go out-of-my-way to state historical information or technical issues, without defining policy.

So I continue to work with people off-list. I hope some results occur soon.

Saying you can do it in 5 minutes but not doing it doesn't help anyone.

I say many things here that cause people to "roll their eyes," many because people don't follow what I'm saying at all. If you are familiar with Red Hat Standard Operating Environment (SOE), like most major Red Hat accounts, they make sense. I think I used the term "Common Knowledge" prior. I should refine it to say "SOE Common Knowledge."

E.g., based on my making the comment ...

"Anyone with a RHN Satellite Server can do the entite media history from the Kickstartable Trees in 5 minutes"

If you have SOE Common Knowledge, you'd immediately hit those Kickstart Trees (e.g., /var/satellite/rhn/kickstart). You can see the channels, the comps.xml and groupings, etc... as the media. And since it's RHN Satellite, you have the full history, right there, immediately available, for every channel you've downloaded.

I hope this explains my prior, "common knowledge" statement as well. ;)

If you're a longstanding enterprise, you likely have not only all the way back to at least RHEL4, if not RHEL3, but likely Extended Update Support (EUS) as well. In fact, EUS is another, historical consideration.

SIDE NOTE: From a 100% technical standpoint, if you want to avoid breakage, avoiding anything also cut for EUS is ideal. This means all of the AS/AP lineage, including RHEL6's HA, LB, RS (GFS2) plus Scalable File System (XFS). Why would we want to do that?

GFS2 and XFS are userspace with kernel dependencies. XFS in particular had a key, kernel-userspace change that required a userspace change. It's one thing for someone to pull userspace from an EL Rebuild or upstream and get breakage, they intentionally did it. But it's another to see it in EPEL, or in the best case, get a dependency issue as a result.

All I can point to is both historical lineage and technical specifics. But until something comes directly from Red Hat, on a redhat.com page and is public, I know most will not be satisfied. Hence why my efforts have been focused on getting that, and to the specifics I've seen stated here, to help others make policy.

I haven't heard anyone here say that. From my perspective there just needs to be some reasonable logic in where the line is drawn that EPEL users can understand.

I've provided it and it's not enough for some. I've accepted that and am working with others to see if there can be a very, very specific document released. I don't want to say more as it's not my place, and I continue to "stick my neck out" (which clearly a couple people want to chop off) trying to get people what they want.

I make *0* policy. I only try to point to things that many people either don't understand, don't believe or otherwise feel is not authoritative enough. Again, I've accepted that, and am doing my best to get something more authoritative. From there, I'll let people decide what they want to do.

I now go back to lurking and working on things with people off-list.

-- Bryan J Smith - Professional, Technical Annoyance

On Fri, Jun 15, 2012 at 12:26 PM, Orion Poplawski orion@cora.nwra.com wrote:

Well, the reason I contribute and maintain packages in EPEL is to support my CentOS and Scientific Linux servers.

I'd like to second this. Keeping EPEL "working well" with CentOS is very important to me, and I know many others that only use EPEL with CentOS servers.

-Jeff

Orion Poplawski orion@cora.nwra.com wrote:

I also don't see a terribly big difference between pulling packages from CentOS or from EPEL.  Wouldn't they have to be the same anyways?

Which does to my greater point ...

If the package is pulled from EL Rebuilds, then it only solves it for EL Rebuilds, not Red Hat Enterprise customers. If the package is pulled from EPEL, it solves it for both EL Rebuilds and Red Hat customers. Both the EL Rebuilds and Red Hat build the packages in their respective release options.

I used to advise Red Hat customers that EPEL was the location where they could get software maintained to Fedora Project standards that did not conflict with Red Hat Enterprise products sans one or two. But now I have to advise with many asterisks, and then I get concern looks -- some of disbelief (until they look into it) and others who just don't want to bother.

The expectations have changed, to the point Red Hat customers have enough issues.

Case-in-point: (Real World, First Hand experience here ...)

These are the exact same issues Red Hat customers moved to EPEL in the first place, away from using things like CentOS Extras. They wanted the extra packages, but not anything that conflicted with Red Hat Enterprise products. But that's no longer the case.

If the EL Rebuilds want to get together and coordinate repos so there is one source for rebuilds from Red Hat SRPMS, I think that's a great idea. But if you make the Red Hat sponsored, Fedora Project's EPEL SIG this repository, then you will just turn EPEL into what many Red Hat customers did not like with CentOS Extras.

And even if the Fedora Project is going to continue to be leveraged for this endeavor, to keep the customers that preferred EPEL over things like CentOS Extras, you're going to need to segment the two. Otherwise they will leave and not come back.

I can't be the only person who has been around Enterprises this long who has seen this over all these years. ;)

-- Bryan J Smith - Professional, Technical Annoyance

On Fri, 15 Jun 2012 22:28:36 +0200 Jan-Frode Myklebust janfrode@tanso.net wrote:

As an enterprice RHEL customer I've always regarded having EPEL enabled on all our servers relatively safe. EPEL is the only external repository we trust. This new policy worries me, because it seems like we no longer safely can have EPEL enabled on servers that subscribe to addons.

Yeah. I can understand that concern.

How do you handle issues between add-ons? Even the base ones I see conflicting packages... do you have RHEL folks handle that and enable them as you like, or is there some kind of "Please dont enable foo and bar because they conflict" you look at?

RHN-channels we currently use for RHEL6 is:

updates supplementary optional rhn-tools rhevm-3 jbappplatform-5 sfs

I don't know off hand what is in those.

On the upside, the new policy seems to allow including the whole sfs-channel in epel, as it's only xfsdump, xfsprogs, xfsprogs-devel and xfsprogs-qa-devel. ..

Does that include the kernel module as well?

kevin

inode0 inode0@gmail.com wrote:

Oh, I missed the EPEL does not conflict with packages shipped by CentOS rule?! Some paying RHEL customers use the two packages for LB from CentOS now and would rather use them from EPEL.

Why is it that every time you respond, you just prove my prior points? ;)

/me goes bang my head

This is not a logical reason to treat lb and ha differently from anything else CentOS might ship. Not to mention RHEL users who get puppet from EPEL when they could pay Red Hat for that too. My problem is mostly just that this seems completely arbitrary to me.

Being a party to this for some time, the mix'n and match'n is turning into a nightmare ... for many. Expectations are changing away from what they were originally, which was much, much easier to deal with.

EPEL is turning into {insert various EL Rebuild distro} Extras. That's nice that it solves it for EL Rebuilds users, since EL Rebuilds can just drop packages from their repos. But what does it do for Red Hat customers?

This is really getting old. The fact that it's getting this confusing, and the expectations are rampantly all-over-the-place, is where I run into the most issues in my real world. I've had to advise accordingly, sadly, which I did not want to.

-- Bryan J Smith - Professional, Technical Annoyance

Stephen John Smoogen smooge@gmail.com wrote:

In this entire thread, you have done NO work beyond long long emails. You haven't come up with a list of packages that would be impacted, you haven't offered to come up with the changes to the build system you would need to make the extra channels. You support no packages in EPEL.

If you say I have no maintainer worth or other record in the Fedora Project and/or EPEL SIG, I'm guilty as charged. No argument.

You have attended no meetings.

I have read each and every meeting log over the last few months. In fact, the only reason I even took an interest was because of customer concerns.

And somehow you are surprised that no one "listens" and the people who have done any or all of the above have an opinion different than yours. Maybe banging your head will enlighten you that your method of 40+ lines emails and multiple responses is not working.

I know we're all busy. And I recognize I've taken out a couple hours a week to write the e-mails. I'm also engaged many more hours on this from customer perspectives as well.

My maintainership is elsewhere right now. I'm sure many have as well, yet they find the time for EPEL maintanership that I do not. At the same time.

But it doesn't mean several of my warnings are not untrue. I think this continued path shoots the project in the foot, and undoes 10 years of RHEL history, including how the EL Rebuilds have traditionally approached add-on channels.

But with that, I will end. I appreciate all of the project leaders on trying to address this and hoping to find a solution. I will go back to lurking and advise my customers correspondingly based on decisions.

-- Bryan J Smith - Professional, Technical Annoyance

On Fri, Jun 15, 2012 at 12:43:52PM -0500, inode0 wrote:

So the build system is os+optional+lb+ha+rs+other stuff I don't recall if I understood previously but EPEL only prohibits shipping packages from os+optional+lb+ha. I'm wondering why the restriction against shipping packages isn't just os+optional here.

My understanding is that the buildsystem is os+optional+lb+ha which is the set of channels that we are saying we won't conflict with. In my view, that part should always remain consistent.

This doesn't address the "How do I tell if a package shipped by Red Hat Channel Foo can be added to EPEL?" question.

-Toshio

On Sat, Jun 23, 2012 at 2:55 PM, inode0 inode0@gmail.com wrote:

On Fri, Jun 15, 2012 at 2:26 PM, Toshio Kuratomi a.badger@gmail.com wrote:

...

On Fri, Jun 15, 2012 at 12:43:52PM -0500, inode0 wrote:

...

So the build system is os+optional+lb+ha+rs+other stuff I don't recall if I understood previously but EPEL only prohibits shipping packages from os+optional+lb+ha. I'm wondering why the restriction against shipping packages isn't just os+optional here.

My understanding is that the buildsystem is os+optional+lb+ha which is the set of channels that we are saying we won't conflict with.  In my view, that part should always remain consistent.

Ok, and that seems to pretty much map to what was included on the RHEL5 distribution media in the side repos for Cluster, ClusterStorage, and VT. On the RHEL6 distribution media there are side repos for HighAvailability (overlaps Cluster in el5), LoadBalancer (overlaps Cluster in el5), ResilientStorage (overlaps Cluster and ClusterStorage in el5), and ScalableFileSystem (not distributed on any media for el5 that I am aware of currently).

...

This doesn't address the "How do I tell if a package shipped by Red Hat Channel Foo can be added to EPEL?" question.

So from looking at this from the perspective of distribution media I would say the current exclusion of HA/LB does logically map in spirit to what was included in Cluster/ClusterStorage in el5. The part that isn't so logical is allowing ResilientStorage. That seems to be in the same category as Cluster/ClusterStorage to me since it overlaps with those packages. Not sure what makes sense with ScalableFileSystem but protecting against conflicts there as well seems most consistent to me (that is the XFS userspace stuff).

To make something of a concrete proposal I think it is logical and easy to understand if we treat HA/LB/RS/SFS in the same manner as they are all delivered to RHEL customers in the same manner. There are two obvious choices for what manner they will be treated.

(1) Disallow conflicts with these packages in EPEL. The upside is that EPEL users know they won't have conflicts with any of these packages from Red Hat. The downside is that it prevents other packages from being included in EPEL that have dependencies from this package set.

(2) Allow conflicts with these packages in EPEL. The upside is more software available in EPEL, both from these channels and from other packages with dependencies on packages in these channels. The downside, conflicts for RHEL customers who use these channels directly. Conflicts can be minimized by careful versioning here.

Some folks will object strongly to both of those options, I believe they already have objected. So maybe there is a place to meet in the middle?

(3) Allow packages from these channels into EPEL as dependencies for other packages using careful versioning to minimize conflicts with those who subscribe directly to these channels. This will allow more software into EPEL, reduce dependency failures for those not subscribing to these channels and minimize conflicts with those who do.

John

On Sun, Jun 24, 2012 at 6:13 AM, Bryan J Smith b.j.smith@ieee.org wrote:

inode0 inode0@gmail.com wrote:

...

(1) Disallow conflicts with these packages in EPEL. The upside is that EPEL users know they won't have conflicts with any of these packages from Red Hat. The downside is that it prevents other packages from being included in EPEL that have dependencies from this package set.

Why would it prevent packages from being included in EPEL?

Because they either won't build due to unresolved dependencies in the build system in the cases of RS and SFS or they will build but produce packages that have unresolved dependencies at install time in the cases of HA and LB. While we do currently have packages in EPEL in this latter category I don't think anyone really thinks it is a good situation and it at the very least contradicts the EPEL note to RHEL6 users that they need to enable the optional channel to satisfy dependencies.

John

On Fri, 15 Jun 2012 12:43:52 -0500 inode0 inode0@gmail.com wrote:

No, I don't want them dropped from the build system. I want to know why piranha can't be packaged by EPEL for example?

We added those channels to the buildsystem due to maintainer requests. I think back when RHEL was in beta we had at least 2-3 maintainers say that they wished to build $foo for EPEL6, but it needed $bar, which was already in one of {ha|lb}, so could we please add them?

I think it's just mostly history at this point.

If we wanted to try and untangle them and drop them from the buildsystem, would that make policy making better/more sane/more clear? I'd like to see what packages that might affect.

ha has 41 packages in it. lb has only 2.

The following epel packages require packages in those 2 repos:

esmtp-0:1.0-7.el6.x86_64 heartbeat-0:3.0.4-1.el6.x86_64 libesmtp-0:1.0.4-16.el6.i686 libesmtp-0:1.0.4-16.el6.x86_64 libesmtp-devel-0:1.0.4-16.el6.i686 libesmtp-devel-0:1.0.4-16.el6.x86_64 pexpect-0:2.3-5.el6.noarch plplot-devel-0:5.9.7-3.el6.1.i686 plplot-devel-0:5.9.7-3.el6.1.x86_64 python-fedora-turbogears2-0:0.3.28.1-1.el6.noarch python-fedora-turbogears2-0:0.3.29-1.el6.noarch python-repoze-who-friendlyform-0:1.0.8-2.el6.noarch python-sprox-0:0.6.11-1.el6.noarch python-suds-0:0.4.1-1.el6.noarch python-tgext-crud-0:0.3.11-1.el6.noarch python-tw-forms-0:0.9.9-3.el6.noarch python-tw-jquery-0:0.9.10-1.el6.noarch python-vatnumber-0:1.0-1.el6.noarch sheepdog-0:0.2.3-2.el6.x86_64 sigul-0:0.97-1.el6.noarch TurboGears-0:1.1.3-2.el6.noarch yumex-0:3.0.5-2.el6.noarch

Note however that much of those are already due to overlap issues.

pexpect is in ha, but also in epel.

In ha: pexpect-0:2.3-6.el6.noarch in epel: pexpect-0:2.3-5.el6.noarch

in ha: python-tw-forms-0:0.9.9-1.el6.noarch in epel: python-tw-forms-0:0.9.9-3.el6.noarch

If EPEL can ship rpms from the resilient storage channel I see no reason not to ship packages from the load balancer channel.

ok.

So the build system is os+optional+lb+ha+rs+other stuff I don't recall if I understood previously

No. This entire thing started because someone asked about glusterfs, which was/is in epel and RS. No conclusion has been made, the buildsystem does not use RS or Other stuff.

You can always look at koji: http://koji.fedoraproject.org/koji/taginfo?tagID=140

but EPEL only prohibits shipping packages from os+optional+lb+ha. I'm wondering why the restriction against shipping packages isn't just os+optional here.

It could be. Would that make the line and expectations more clear?

Would that cause less trouble for people?

kevin

On 06/15/2012 05:35 PM, Orion Poplawski wrote:

Any way to ask yum to install all packages from a specific repo while still having all repos enabled? Might be interesting to see the output of something like:

yum install <all of epel>

on a base rhel6 box.

Partial attempt, I'm missing some packages in epel, and some may be missing deps in epel, but it doesn't seem that many.

Error: Package: easybashgui-4.0.2-2.el6.noarch (epel) Requires: xdialog Error: Package: spacewalk-admin-1.8.3-1.el6.noarch (epel) Requires: spacewalk-base Error: Package: heartbeat-libs-3.0.4-1.el6.x86_64 (epel) Requires: libpils.so.2()(64bit) Error: Package: tpp-1.3.1-9.el6.noarch (epel) Requires: vim-filesystem Error: Package: heartbeat-libs-3.0.4-1.el6.x86_64 (epel) Requires: libplumbgpl.so.2()(64bit) Error: Package: sheepdog-0.2.3-2.el6.x86_64 (epel) Requires: libcpg.so.4()(64bit) Error: Package: heartbeat-libs-3.0.4-1.el6.x86_64 (epel) Requires: libplumb.so.2()(64bit)

Error: Package: ScientificPython-qt-2.8-15.el6.x86_64 (epel) Requires: PyQt Error: Package: fawkes-devenv-0.4.2-3.el6.noarch (epel) Requires: gearbox-devel >= 9.11 Error: Package: bluecurve-icon-theme-8.0.2-6.el6.noarch (epel) Requires: bluecurve-cursor-theme Available: bluecurve-cursor-theme-8.0.2-6.el6.noarch (epel) bluecurve-cursor-theme = 8.0.2-6.el6 Error: Package: gpodder-2.19-1.el6.noarch (epel) Requires: python-eyed3 Error: Package: tpp-1.3.1-9.el6.noarch (epel) Requires: ruby-ncurses Error: Package: gpodder-2.19-1.el6.noarch (epel) Requires: python-pymtp Error: Package: mon-1.2.0-8.el6.x86_64 (epel) Requires: perl(Net::Telnet) Error: Package: rubygem-treetop-1.4.10-1.el6.noarch (epel) Requires: rubygem(polyglot) Error: Package: sheepdog-0.2.3-2.el6.x86_64 (epel) Requires: libcfg.so.4(COROSYNC_CFG_0.82)(64bit)

Error: Package: heartbeat-3.0.4-1.el6.x86_64 (epel) Requires: libplumb.so.2()(64bit) Error: Package: perl-Net-Telnet-Cisco-1.10-4.el6.noarch (epel) Requires: perl(Net::Telnet) >= 3.02 Error: Package: sheepdog-0.2.3-2.el6.x86_64 (epel) Requires: libcpg.so.4(COROSYNC_CPG_1.0)(64bit) Error: Package: sheepdog-0.2.3-2.el6.x86_64 (epel) Requires: corosync

Error: Package: heartbeat-libs-3.0.4-1.el6.x86_64 (epel) Requires: libstonith.so.1()(64bit)

Error: Package: mysql-utilities-1.0.5-3.el6.noarch (epel) Requires: mysql-connector-python

Error: Package: heartbeat-3.0.4-1.el6.x86_64 (epel) Requires: cluster-glue-libs

Error: Package: rubygem-right_aws-2.0.0-1.el6.noarch (epel) Requires: rubygem(right_http_connection) >= 1.2.4 Available: rubygem-right_http_connection-1.2.4-2.el6.noarch (epel) rubygem(right_http_connection) = 1.2.4 Error: Package: heartbeat-3.0.4-1.el6.x86_64 (epel) Requires: resource-agents Error: Package: sheepdog-0.2.3-2.el6.x86_64 (epel) Requires: libcfg.so.4()(64bit) Error: Package: spacewalk-admin-1.8.3-1.el6.noarch (epel) Requires: perl(RHN::SatelliteCert) Error: Package: pcp-import-sheet2pcp-3.6.3-1.el6.x86_64 (epel) Requires: perl(Spreadsheet::Read) Error: Package: heartbeat-3.0.4-1.el6.x86_64 (epel) Requires: cluster-glue

On Sat, 23 Jun 2012 16:51:46 +0100 "Richard W.M. Jones" rjones@redhat.com wrote:

Kevin, about the provision to provide packages for other binary architectures.

RHEL 6 supplies qemu-kvm only on x86-64. This provision lets us provide qemu-kvm on i386 and ppc64 I think.

Yeah.

The exact policy is:

http://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages

My questions:

Does it have to be the same n-v-r of qemu-kvm? (This seems like it would be impossible in practice, so I guess the answer must be no)

No, it needs to be less than the one provided by RHEL.

ie, a leading 0 on the release...

Can the other arches be provided by a differently named package? (We call it 'qemu' in Fedora)

I don't know. It would complicate things on versions, etc.

Can the EPEL package override the x86-64 package from RHEL, eg. by providing qemu-kvm.x86-64 with a higher n-v-r? Or should the EPEL package ExcludeArch the RHEL packages that exist?

The EPEL version should be a lower n-v-r than the RHEL one. However, due to the way koji works, when we setup a package like this, it's the EPEL version on all arches that is seen/used in the buildsystem. There's no way to tell koji to block a package in only one arch or look for it in only some other ones.

kevin

On Fri, 6 Jul 2012 09:37:24 +0100 Paul Howarth paul@city-fan.org wrote:

So koji has no support for yum's "cost" parameter then? Assigning a "cost" of more than 1000 to EPEL would get yum to prefer other repos (e.g. RHEL) to it when there were packages of equal NEVR in multiple places.

Nope. My understanding is that it does not.

kevin