There needs to be some additional checking here. packages in RHEL are allowed in EPEL if the package is only shipped on a subset of arches. there is a bunch of packages useful and needed on non x86 that are only shipped in RHEL on x86

There needs to be some additional checking here. packages in RHEL are allowed in EPEL if the package is only shipped on a subset of arches. there is a bunch of packages useful and needed on non x86 that are only shipped in RHEL on x86

@ausil thank you for the info. With that, I'm not sure how the tooling can help here since when a user requests an EPEL branch, we don't know what architecture they're planning to build it on. Should I then just restrict EPEL branches based on if a package is provided for all architectures that EPEL is built for? In all other cases, I could then leave it up to the admin processing the tickets to make the decision of if this should have an EPEL branch.

@mprahl the json has the arches a package is available for in RHEL. if its not available on all its eligible to have a EPEL branch

@mprahl the json has the arches a package is available for in RHEL. if its not available on all its eligible to have a EPEL branch

It likely should warn (but not error out) in this case. ie, "Warning: package exists in RHEL and EPEL branch requested, but RHEL does not cover all arches, does this package follow https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages ?"

I found there is infrastructure.stg.fedoraproject.org. Is this usable? Probably it should be used for fedpkg-stage.

FYI: if name in rv.json()['packages']:

We can simplify this with six.assertRaisesRegex.

@ausil @cqi thank you for the reviews. May you please take a look again?

@mprahl the json has the arches a package is available for in RHEL. if its not available on all its eligible to have a EPEL branch

It likely should warn (but not error out) in this case. ie, "Warning: package exists in RHEL and EPEL branch requested, but RHEL does not cover all arches, does this package follow https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages ?"

Thank you for the link!

After talking with @ausil, it seems like we have the cases covered enough to error out, and any exceptions can be tickets filed with Release Engineering as stated in the error message.

I'm trying to make the logic as concrete as possible so that eventually, the admin tool that processes these tickets (fedrepo-req-admin) could have its parts migrated to a microservice to automatically process some tickets. For the record, I'm not planning such a microservice but I believe it's an eventual goal for Release Engineering to have this.

el6 actually ships 32 bit, only ppc should be removed here

Thanks for the review. I think we decided to remove "i386" on EL6 checks because the kernel on EL6 says it has the following arches [u'i686', u'noarch', u'ppc64', u'x86_64'] but EL6 ships these arches [u'i686', u'noarch', u'i386', u'ppc64', u'ppc', u'x86_64']. If we didn't remove "i386" from the checks then someone would be able to request an EPEL branch for the kernel on EL6.