On 09/13/2016 01:28 PM, Stephen John Smoogen wrote: > On 13 September 2016 at 14:13, 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.". >> > > Limited arch packages are ones where you are building something for > say ppc or aarch64 which has a RHEL package already in x86_64 but no > corresponding RHEL ppc or x86_64 one. The reason to put a 0. in front > is that sometimes RHEL does offer such packages later in a release > cycle and we want that version to overwrite anything we built to > satisfy a dependency. [Also if CentOS builds all the packages for > their port of EL-X to PPC or aarch64 we do not conflict with their > packages.] > > This is only meant for that case. > >> 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. >> > > The reasoning for needing a python3-foobaz is that we don't replace > the python2 version of foobaz with a package which does not work at > all with the python2 installed and possibly breaks an existing app. > > My personal take is that all python3 apps should be called python3 in > their names and all python2 apps should have been called python2 as > every time python does these major updates we end up with years of > maintaining this split brain damage which lasts longer than the > language version exists. I'm in the process of working through this for a few python bits for EPEL7. While I generally agree, it's problematic at times because the fedora sources provide a sane split for this, while the EL sources do not. This occasionally means creating a new package just for EPEL rather than simply branching the fedora tree. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 _______________________________________________ epel-devel mailing list epel-devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
