On Tuesday, September 13, 2016 5:35:29 PM CDT Neal Gompa wrote: > On Tue, Sep 13, 2016 at 5:26 PM, Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > On Tue, 13 Sep 2016 14:13:44 -0400 > > > > Avram Lubkin <aviso@xxxxxxxxxxxxxx> 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. > > > > 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. > > > > 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. > > That doesn't make sense. Builds are done by pulling in base, epel, and > buildroot repositories into a generated mock config and executed (i.e. > passed to mock to build the SRPM and then the RPMs). No part of mock > would have a problem here. Therefore, there is no reason for the > absurdity of having python3-* SRPMs. > > Sure, Koji operates on SRPMs, but Fedora Koji does not build RHEL or > CentOS. So this particular problem doesn't exist from that perspective > either. Content from RHEL/CentOS essentially is a black box to Koji. The koji repos will only include binary packages from exactly one source rpm of a given name. koji builds its own repos and does not use the repos in the way you think and you would at home. Koji was tought to treat external repos exactly the same as internal repos. Net result being if you rebuild python-foo to get a python3 build you will have to also build python2 version and ensure that the nvr is lower. The only realistic option given that there will be python3 mass rebuilds as python versions change is to have python3 specific srpms Dennis _______________________________________________ epel-devel mailing list epel-devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
