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
- Start with just a few of the most important packages, like python-setuptools.
- Each of those gets a separate python2-X package. This is a separate git repository, not something genreated from an EPEL branch of the regular python-setuptools 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.
- Using 1 when possible and coming up with something when necessary is probably smartest.
- Have to look at the list of all prospective packages and see where using 1 won't work.
- 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 to do first
- python-setuptools (only in EL6 as EL7.4 has finally added the python2-setuptools provide):
- python-sphinx:
- pytest:
- python-six:
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