Re: [opensuse-buildservice] introducing new macros across the whole OBS?
On Thu, Nov 10, 2016 at 7:49 AM, jan matejek <jmatejek(a)suse.com> wrote:
Hello,
in relation to the python single-spec initiative, I have designed a set
of new macros that allow significant automation in building Python packages.
However, these are constrained by the %python_module macro used in
BuildRequires.
The purpose of this macro is to expand %{python_module foo} to
python2-foo, python3-foo, etc., based on which python flavors are build
targets for the package. Obviously, the buildservice itself must be able
to do this expansion, otherwise it can't resolve the build requirements.
So far I have solved this by placing all the macros in prjconf. But this
is not viable if I want my macros to be available everywhere. I can
create a "python-macros" package for all the other macros, and
buildrequire it, in order to make the packages build in any distro that
has this package, but I can't do the same for %python_module.
Is it possible to make the buildservice itself recognize this macro, or
place it in some sort of global prjconf? Ideally without triggering a
full rebuild of everything?
Or do you have any tips for alternate solutions?
One thing that occured to me, instead of relying on macros, turn
"python-foo" packages into metapackages requiring the respective
"python2-foo", "python3-foo" etc., and then BuildRequire the
metapackage. I don't have a clear idea about how well this would work,
it seems rather problematic.
I don't want to make packagers list the buildrequires by hand, because
the requirements can be numerous and we also want to be able to add more
python flavors and expand the build requirements accordingly.
thanks for any tips
m.
Why not pull in the dependency generator I upstreamed into RPM[1] into
openSUSE? Fedora is using it now in Fedora 25 and Rawhide[2][3], and
Mageia is using an earlier variant of it now. It establishes common
names for Python packages that provide egg-info or dist-info data
(egg/wheel metadata installed on the system) that can be used for
standardizing how Python dependencies are referenced.
Fedora is currently only using it for Provides generation at the
moment, but Mageia uses it for Provides and Requires generation. That
would make it less onerous in general to package Python stuff, as it
would gain useful dependency generation like Perl and Ruby have. Tools
like pyp2rpm[4] can use these names for generating good spec files
that can build packages properly. Petr Viktorin gave a presentation at
Flock 2016[5][6] about the future of Python packaging in Fedora, with
this as a key staple.
[1]: https://github.com/rpm-software-management/rpm/blob/master/scripts/python...
[2]: http://pkgs.fedoraproject.org/cgit/rpms/rpm.git/tree/
[3]:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedorapr...
[4]: https://github.com/fedora-python/pyp2rpm
[5]: https://speakerdeck.com/encukou/python-packaging-in-fedora
[6]: https://www.youtube.com/watch?v=rp5jq-25nZg
--
真実はいつも一つ！/ Always, there's only one truth!