Thoughts from last meeting

Kevin Fenzi kevin at scrye.com
Fri May 25 22:05:07 UTC 2012


On Fri, 25 May 2012 16:45:39 -0500
inode0 <inode0 at gmail.com> wrote:

> On Fri, May 25, 2012 at 4:24 PM, Kevin Fenzi <kevin at scrye.com> wrote:
> > So, at our last meeting:
> >
> > http://meetbot.fedoraproject.org/meetbot/teams/epel/epel.2012-05-23-22.12.html
> >
> > There seemed to be a fair bit of push to change our policy from:
> >
> > "EPEL6 will not ship any packages that have src.rpms on public
> > mirrors under 6* directories with the following exception: If the
> > binary rpm is only shipped in some arches in RHEL, EPEL may ship a
> > package as close as possible to the RHEL version with a leading
> > package Release of 0. (ie, libfoo-1.2-0.x) (note that EPEL
> > maintainer must keep up exactly with the RHEL src.rpm where
> > possible)."
> >
> > to
> >
> > "EPEL6 will not ship any packages that have src.rpms on public
> > mirrors under 6-Server, 6-Server-ha, 6-Server-optional,
> > 6-Server-lb, except
> 
> What is the logic behind protecting only these two layered products?
> Seems if we are ignoring other layered products we might as well just
> ignore all layered products and greatly simplify things.

These are all channels that are enabled in our buildsystem: 
http://koji.fedoraproject.org/koji/taginfo?tagID=140

I think we enabled them for two reasons: a) rhel5 had the similar
channels enabled, b) we have some things in epel that needed items in
those channels to build. 
> 
> > packages missing in one of our supported arches may be shipped by
> > EPEL, but must abide by
> > http://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages.
> 
> I really like this policy.

It still needs a concrete list of packages that are using it, but I
hope to work on that this weekend if I get time. ;) 

> > Additionally, EPEL will drop packages that overlap with other RHEL
> > channels/layered products on request of those channel owners"
> 
> What is the concern here? How would this impact the owners of the
> layered product channels?

If layered product folks start getting a flood of "I'm using version
$foo of your product" and thats the version shipped in RHEL instead, we
might drop this from EPEL to avoid causing undue support burden on
them? Then again, another layered product might say "well, thats not
what we ship, reinstall with $foo before we support you" Or another one
might say "we think it's great that EPEL ships this so we can get more
people testing it and providing feedback". 

I don't know off hand, this was just a way to make sure we didn't cause
problems for layered product people. 

> The RHEL owner can provide if for all channels and that will remove it
> from EPEL. I don't see any reason for them to just remove it from EPEL
> while not providing it universally in RHEL.

Perhaps. I don't know whats involved in all that. Perhaps their are
reasons it's difficult. 
> 
> > Anyhow, thoughts? concerns?
> 
> As an EPEL consumer I find this all rather confusing. I don't want to
> have to know which layered products are protected and which aren't. I
> think I'd rather live with a simpler uniform policy regarding layered
> products.

So, you would suggest dropping the ha and lb products from overlap?
Or making it so no channels can overlap?

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20120525/91dce0df/attachment.sig>


More information about the epel-devel-list mailing list