On Tuesday, September 13, 2016 11:54:41 PM CDT Peter Robinson wrote: > >> I'm looking for some clarification on the naming requirements for > >> SRPMs. > >> > >> In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names > >> can't conflict with RHEL SRPM names, but in the Limited Arch Packages > >> [2]section of EPEL: Packaging, it seems to imply the SRPM name would > >> be the same, but the release number would be pretended with "0.". > >> > >> Could someone please clarify? > >> > >> If, in fact, the name can be the same, it will make it much easier to > >> provide Python 3 packages for EPEL since a separate package would not > >> be required in the Fedora Package DB. > > > > So, here's the thing (at least as I understand it): > > > > koji operates on source packages. > > > > If there's a package in RHEL called 'foo' and also one in EPEL called > > 'foo' it will use the epel one in all cases for everything that foo > > makes. > > Is that the case with external repos? I didn't think it was that smart > in that case, but I'm tired so might be mis-remembering. It 100% is the case. Koji treats external repos exactly the same as internal. it even taks special care to ensure that all binary rpms for a given srpm are included even if the binary rpms are spread acorss different external repos
> > So, with the limited arch packages this means that _ALL_ things > > building in koji will use the epel package. The reason for the > > prepended 0 is so that users don't install the epel package and instead > > get the newer rhel version. The limited arch guideline also says you > > should try and keep the package as close as possible to the rhel > > version. > > For el7, and even in some of the big (java*) use cases in el6 the > delta in packages between the arches is getting a lot less, and I > believe this will be more so as we move forward in el7. I honestly am not sure there is any limited arch packages in epel7 > > So, if we had say: python-foobar-1.0-1.el7.src.rpm in rhel that made a > > python-foobar-1.0-1.noarch.rpm and then we made a epel > > python-foobar-1.0-1.el7.src.rpm that had > > python3-foobar-1.0-1.noarch.rpm it would mean anything that builds > > against python-foobar in epel would break (it would be not found). End > > users would be ok, but buildroots could be broken by it. > > > > So we are kinda in a lerch here... I think the best way is just new > > packages with python3-whatever. > > > > kevin > > > > > > > > _______________________________________________ > > epel-devel mailing list > > epel-devel@lists.fedoraproject.org > > https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject > > .org > _______________________________________________ > epel-devel mailing list > epel-devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.o > rg _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
