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 06-24-2012, 03:49 PM
Bryan J Smith
 
Default Overlap policy v20120615

inode0 <inode0@gmail.com> wrote:
> Because they either won't build due to unresolved dependencies
> > in the build system in the cases of RS and SFS

I thought Red Hat is providing the necessary add-on entitlements? If
not, that needs to change, especially since "EL Rebuilds" provide
them.

> or they will build but produce packages that have unresolved
> dependencies at install time in the cases of HA and LB.

Which means there should be a tool (e.g., YUM plug-in) that notifies
Red Hat customers of what entitlements they are missing. I can see
several approaches where Red Hat could offer this.

> While we do currently have packages in EPEL in this latter category
> I don't think anyone really thinks it is a good situation

Why not?

Red Hat customers should have the option to either:
A) Assign (or acquire, if necessary) the necessary entitlements, or
B) Find an alternative, open source option to them (e.g., EL Rebuilds)

I'm for notifying the Red Hat customer when they do not have the
necessary entitlements, instead of blindly doing it for them, possibly
causing them additional support issues.

> and it at the very least contradicts the EPEL note to RHEL6
> users that they need to enable the optional channel to satisfy
> dependencies.

As I've been constantly asking throughout all of these threads ...

How is this any different than EPEL5 or earlier? Or is it only more
recently that people have started to build against the various -devel
and add-on packages, and are only doing this against EPEL6?

Scalable File System (SFS aka XFS) was added to RHEL5 as well.
Resilient Storage (RS aka GFS2) has been around since RHEL5 too (and
GFS in even earlier).

Am I missing something here? None of this lineage has changed. I am
completely open to being corrected. But as I have shown time and time
again, I've been fairly accurate.

But for some reason, and to use the term you used, "concrete" hasn't
been applied to my replies, despite my research and e-mails
(especially those off-list, which you did receive too).


--
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 07-05-2012, 11:04 PM
Kevin Fenzi
 
Default Overlap policy v20120615

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
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 07-06-2012, 08:37 AM
Paul Howarth
 
Default Overlap policy v20120615

On Thu, 5 Jul 2012 17:04:32 -0600
Kevin Fenzi <kevin@scrye.com> wrote:

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

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.

Paul.

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 07-06-2012, 11:41 PM
Kevin Fenzi
 
Default Overlap policy v20120615

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
_______________________________________________
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 03:46 AM.

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