(python-zope-interface) |
(Updates for python-zope-interface) |
||
| Line 51: | Line 51: | ||
== Packages in progress == | == Packages in progress == | ||
Buildroot overrides are active for all of these, so they can be used in koji builds now. Please test and give karma! | Buildroot overrides are active for all of these, so they can be used in koji builds now. Please test and give karma! | ||
* python-zope-interface | |||
** EPEL7 - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-a3e7bd9aee | |||
** EPEL6 - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-890235d0f2 | |||
* python-docutils | * python-docutils | ||
** EPEL7 - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b80060f45f | ** EPEL7 - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b80060f45f | ||
Revision as of 02:49, 24 February 2018
Packagers would like to support both Fedora and EPEL releases with common specfiles wherever possible. Pretty much anything can be done using conditionals (%if/%endif) but this can be annoying and has a cost in specfile legibility. It would be nice if there was some alternative.
It is assumed up front that simply having Provides: python2-X added to the RHEL packages in question is not a possibility. While Red Hat may decide do some of this in RHEL7 point releases, there is very little chance that RHEL6 will change.
The current proposal
- Each package without a python2-* provide gets a separate python2-X stub package. This is a separate git repository, not something generated from an EPEL branch of the regular repo.
- They will carry the %version from the base RHEL package.
- Release technically shouldn't matter as long as it's <= the release of the RHEL package. To avoid any potential issues if the RHEL package does grow the python2-* provide, it can never be greater.
- Making the releases equal gives us no wiggle room in case we need to update the stub package for whatever reason.
- Using 0 is technically a guidelines violation, but one that's easily justified.
- In the case where RHEL packages a prerelease, we really need to start from 0 and move to something like 0.0.1. (docutils in EL7 has release 0.2.<date> so the plan has to allow a way to stay below that.)
- The individual packages will carry no files at all, just a single versioned Requires: on the base package.
- This should take the form Requires: python-X >= %version.
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.
Maintenance needed
These packages must be immediately retired if an update to the base RHEL package starts providing python2-X. However, keeping the release at a lower value means that nothing will break if there's a delay; there will simply be a brief period where both EPEL and RHEL provide the same package, but the RHEL one is newer.
The version should be updated if the version of the base RHEL package changes, so that versioned dependencies work as expected. This can be scripted using https://infrastructure.fedoraproject.org/repo/json/pkg_el7.json and phg_el6.json and a small bit of code.
Why don't we....
- Just stuff these all in a single source package, which can spit out a bunch of these stub packages without all of the hassle of maintaining everything separately?
Because then we'd have to bump the release of all of those generated packages when we just need to change one. Since we have to keep the release strictly lower, things get difficult.
- Use an unversioned Requires: on the base package?
Because this could lead to a situation where a package requires python2-foo >= 3, which in turn requires any version of python-foo. If a host hasn't updated and so still has python-foo version 2 then the dependencies would all technically be satisfied but things wouldn't actually work.
- Use a strict version dependency on the base package?
Because this could prevent RHEL upgrades if the RHEL package is updated but the EPEL package isn't.
- Just use an EPEL branch of the existing package repository?
Because that would make the source package name python-X, which would really look like a duplication between base RHEL and EPEL. To avoid any possibility of confusion a new repository is needed.
Open questions
Is there any situation where these packages will cause some problem for end users?
Packages already done
- python-setuptools (EL6 only, not needed in EL7)
- pythyon-sphinx
- pytest
- python-six
Packages in progress
Buildroot overrides are active for all of these, so they can be used in koji builds now. Please test and give karma!
- python-zope-interface
- python-docutils
- python-requests
- python-dateutil
Packages to do next
Feel free to suggest more by adding them here.
The skeleton spec
%global dummy setuptools
Name: python2-%dummy
Version: 0.6.10
Release: 0%{?dist}
Summary: Dummy package depending on python-%dummy
License: Public Domain
Requires: python-%dummy >= %version
BuildArch: noarch
%description
This package exists only to allow packagers to uniformly depend on
python2-%dummy instead of conditionalizing those dependencies based on the
version of EPEL or Fedora. It contains no files.
%files
%changelog