[EPEL-devel] Re: Stub python packages for EPEL
On 08/04/2017 12:37 PM, Jason L Tibbitts III wrote: >> "KF" == Kevin Fenzi writes: > > KF> I don't think we have any way to find out the version of a package > KF> in all channels. At least I don't know of such a way. So, I think we > KF> should concern ourselves with only the channels that EPEL says it > KF> will try and not conflict with. > > I don't even know what those are, really. All I know is what I can > extract from those json files, and what CentOS has. Certainly limiting > things to what EPEL can see is the only reasonable way; I was just > trying to hedge against the fact that I can't see what's in The json files we provide are the exact channels that epel uses and tries not to collide with. RHEL has hundreds (thousands?) of other channels we don't look at. > KF> So, yeah, we would need to make sure and retire the epel package as > KF> soon as rhel started providing a source package with the same name. > > I think it is somewhat unlikely that RHEL would begin providing any > python2-X source packages where they currently provide python-X source > packages. I guess it's possible, though, and it's something we'd have > to deal with immediately if it ever happens. However, it shouldn't > cause issues for end-user systems in that case, only the EPEL builders, > and for those the fix is very quick (block in koji and wait for a newrepo). Yep. > KF> I'm in favor... lets give it a try with some of the common ones. :) > > Thanks; I have a list of four I'm starting with, listed at the end of > https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages > > I hope that once in this will make life easier for someone. Indeed. Thanks for working on this. kevin signature.asc Description: OpenPGP digital signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: Stub python packages for EPEL
> "KF" == Kevin Fenzi writes: KF> I don't think we have any way to find out the version of a package KF> in all channels. At least I don't know of such a way. So, I think we KF> should concern ourselves with only the channels that EPEL says it KF> will try and not conflict with. I don't even know what those are, really. All I know is what I can extract from those json files, and what CentOS has. Certainly limiting things to what EPEL can see is the only reasonable way; I was just trying to hedge against the fact that I can't see what's in KF> So, yeah, we would need to make sure and retire the epel package as KF> soon as rhel started providing a source package with the same name. I think it is somewhat unlikely that RHEL would begin providing any python2-X source packages where they currently provide python-X source packages. I guess it's possible, though, and it's something we'd have to deal with immediately if it ever happens. However, it shouldn't cause issues for end-user systems in that case, only the EPEL builders, and for those the fix is very quick (block in koji and wait for a newrepo). KF> I'm in favor... lets give it a try with some of the common ones. :) Thanks; I have a list of four I'm starting with, listed at the end of https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages I hope that once in this will make life easier for someone. - J< ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: Stub python packages for EPEL
On 08/01/2017 10:41 AM, Jason L Tibbitts III wrote: > One of things I've invested some time towards over the years is cutting > down on the amount of %if spaghetti needed to share spec files between > Fedora and EPEL. Earlier in the discussion about the mass python-X -> > python2-X move I volunteered to maintain a number of "stub packages" in > EPEL which have the sole purpose of letting packagers uniformly have > dependencies on python2-X. A couple of people told me they thought I > was being facetious, so I wanted to try again and assure everyone that I > was indeed serious. > > Here's a rough, in-progress draft: > > https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages > > Basically: create some EPEL-specific python2-X packages that do nothing > besides depend on the base RHEL python-X packages. > > If anyone can think of a reason why this would be problematic, please > let me know. I'm especially concerned about situations where the > existence of these packages could cause problems for RHEL. I've tried > to be careful about detailing how version and release would be > maintained and how the dependencies will be versioned so that RHEL can > be updated without the EPEL package being immediately updated to match. A few comments: "Since in RHEL it's possible for one package to have many different versions in various channels, it makes sense to try to stick with the lowest version that's in any channel. In any case, EPEL is limited in what channels it supports. " I don't think we have any way to find out the version of a package in all channels. At least I don't know of such a way. So, I think we should concern ourselves with only the channels that EPEL says it will try and not conflict with. Note that there is a case here if rhel and epel have a source package with the same name, the epel one will be used in all buildroots no matter what the versions. So, yeah, we would need to make sure and retire the epel package as soon as rhel started providing a source package with the same name. If they are still different source packages then the newest one would win. I'm in favor... lets give it a try with some of the common ones. :) kevin signature.asc Description: OpenPGP digital signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org