User:Tibbs/EPELPythonStubPackages

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.
• 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: base name >= %version.

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

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

Open questions

Is there any situation where these packages will cause some problem for end users?