Nice job, Miro!
Thanks a lot for working on this.
On Fri, Apr 3, 2020 at 8:45 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
>
> Hello Python packagers.
>
> I have just updated python-rpm-generators to python-rpm-generators-11-1.fc33 in
> Rawhide. It uses some fresh stuff from RPM 4.16 and will not be backported to
> older releases.
>
>
> The python(abi) requirement is now added from a RPM Lua macro, instead of by
> executing a Shell script. This is a bit faster especially for packages with a
> lot of files. For 10 000 files in one package, the speedup is roughly from ~80
> to ~2 seconds (time of the entire package build incl. creating the files from a
> Python script). That is a lot, but most of the real packages have much less
> files, so I am afraid you won't feel it.
>
>
> More importantly, %python_provide is not needed for package names.
> Until now, we needed to this:
>
> %package -n python3-foo
> ...
> %{?python_provide:%python_provide python3-foo}
>
> This adds automatic provides "python-foo" (and since recently, also
> "python38-foo" for forwards/backwards compatibility with EL). This now happens
> automagically. Any package called "python3-..." will have those provides added
> implicitly by the Python generators when they are in the buildroot
> (python3-devel brings those in, so for Python packages this means always).
>
> This automation was possible due to the speedup mentioned above, doing it the
> pre-RPM.16 way would be very slow, because the generator is called for every
> packaged file (which is still the case now, but it can now be a Lua macro). The
> ~2 seconds from above include this new feature.
>
> There are 2 cases where manual %python_provide calls are still needed:
>
> 1. Metapackages without files
>
> No files => no dependency generator. (I recommend to %ghost the
> dist-info/egg-info directory in such packages to workaround this -- we plan to
> add more good stuff regarding Python [extras] that will require this anyway.)
>
> 2. Virtual provides
>
> The dependency generator can see the (sub)package's name, but not any other
> virtual provides. When you do:
>
> %package -n python3-%{pypi_name}
> Provides: python3-%{legacy_name} = %{version}-%{release}
>
> You are still supposed to add:
>
> %{?python_provide:%python_provide python3-%{legacy_name}}
>
> (Also note that %python_provide adds obsoletes for older python-foo versions,
> that was useful when we renamed everything from python-foo to python2-foo and
> when we changed the "default" from python2- to python3-. We are keeping the
> Obsoletes in the macro (for now), but I have decided to not automatically
> generate the Obsoletes based on the package name. A) I don't consider them
> really needed in Fedora 33 any more and B) an idea of implicit obsoletes doesn'T
> sound very intriguing to me. This is a decision that may be revisited later if
> it's bringing unforeseen trouble.)
>
> You don't need to to actively remove the macro from your spec files, it does no
> harm. If you prefer to maintain a single spec, keep it there until Fedora 32
> goes EOL (and EPEL 8 if that's your target). The guidelines always recommended
> using it the safe way (%{?python_provide:...}), so even if it ceases to exist in
> the future, it can remain in specs. There is no plan to remove it in any near or
> distant future, as it is still needed for the virtual provides. The generators
> also use it internally (for DRY and consistent results).
>
> If you'll get into trouble because of this, let us know and we'll fix it.
>
> I'll make a note for myself to update the Python packaging guidelines.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> _______________________________________________
> python-devel mailing list -- python-devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to python-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/python-devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx
