No, this automatic Provides generator does not create "python(name)". Only "pythonX.Ydist()" and "pythonXdist()".

On 08/10/2016 07:09 PM, Avram Lubkin wrote:
Is an unversioned python(name) also being created automagically? I manually create these for the command line tools which support multiple Python versions, where the python2-name and python3-name package both provide python(name) and then the name package requires python(name) with a recommends for one or the other.

On Wed, Aug 10, 2016 at 12:38 PM, Petr Viktorin <pviktori@redhat.com> wrote:

To help automatic building RPMs from native Python packages, we need an
automatic way to record the software's upstream name (dist name, name
on PyPI) in Fedora packages.

For this, we are using RPM's automatic dependency generator written by
Per Øyvind Karlsen and Neal Gompa, which automatically scans
".dist-info" and similar files and generates virtual Provides,
currently in the form "pythonX.Ydist(name)".
(The generator was originally developed for Mandriva and Mageia; finally
it's coming to Fedora as well!)
The Fedora Change page for this feature is here:

Unfortunately, while implementing this, we failed to understand how the
virtual provides work with source RPMs. This leads to the situation
that, as currently planned, the automatic provides are only useful in
"Requires" lines, not in "BuildRequires".

The problem is that if a requirement like "python3.5dist(name)" is
present in a SRPM, the SRPM can't be rebuilt on systems with other
Python versions, which would provide, say, "python3.6dist(name)".
For these systems, the SRPM would need to be rebuilt, which not all
tools do.

Igor Gnatenko (ignatenkobrain) explained this on IRC on #fedora-python,
after which we had a long discussion about the problem and possible
solutions. We're sorry for not getting this earlier -- despite several
people mentioning it (including Neal who wrote the generator)!

The fix is to enable "--majorver-provides" in the dependency generator,
so that each package will provide two forms of the virtual provide:
The full version should then be used for runtime Requires, while the
one with major version only should be used for BuildRequires.

We'll wrap this up in easy-to use (and hopefully future-proof) macros:

* One macro for getting the canonical (normalized) dist-name:
    %{python_dist_name NAME}

* Four macros for adding Requires and BuildRequires lines (which use the
  python_dist_name macro above):

  %{requires_python3_dist NAME} => Requires: python3.Ydist(name)
  %{buildrequires_python3_dist NAME} => BuildRequires: python3dist(name)
  and similarly for Python 2.

An alternative would be macros that don't include the keyword "Requires:" or
"BuildRequires:". This would result in specfiles with lines like:
    BuildRequires: %{python3_dist_br name}
    Requires: %{python3_dist name}
This would be susceptible to people copying the Requires line, adding
"Build" to the front, and forgetting to change the macro as well,
leading to a hard-to-catch failure (working binary RPMs but SRPMs that
fail to rebuild on other distro versions).
Macros that include the keyword are more robust to copy-pasting.

Since the %buildrequires_python3_dist and %python_dist_name macros will
be used in the SRPM, they'll need to go in macros.python-srpm to be
present in the default buildroot.
The %requires_python3_dist macro (and %pythonX_version) can live in

Following is the new road plan:

# Plan for Fedora 25:
* The 5 macros will be created and deployed.
* The --majorver-provides swich for the Provides generator in Fedora RPM will
  be enabled
* Fedora Packaging Guidelines for Python will be amended:
    * The addition of the pythonX.Ydist(..) tags will be explained.
    * The %{python_dist_name} macro will be advertised.
    * The %{requires_pythonX_dist} macros will be advertised for use in
      generating Requires tags.
    * It will be explained that, at this time, it is impossible to
      generate BuildRequires without the providing package being
      rebuilt, so the %{buildrequires_pythonX_dist} macros will be
      discouraged for now.
* See if we can get in another targeted mass rebuild. If yes, continue
  with the f26 plan early.

# Plan for Fedora 26:
* All Provides will be regenerated in the regular Fedora 26 mass rebuild
* Change Python guidelines so the %{buildrequires_pythonX_dist} macros
  are now encouraged.

Petr Viktorin
python-devel mailing list

python-devel mailing list