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(a)scrye.com>
wrote:
> On Tue, 13 Sep 2016 14:13:44 -0400
>
> Avram Lubkin <aviso(a)rockhopper.net> 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