Mailinglist Archive: opensuse-packaging (53 mails)

< Previous Next >
Re: [opensuse-packaging] python single-spec progress, questions
On 10/27/2016 12:51 PM, jan matejek wrote:
hello packagers,

i'm happy to announce that i have a macroset that works pretty well, if
i say so myself :)
Have a look at the d:l:python:singlespec repository [1] and the github
repo [2] for details.

The gist of it: it is now very possible to build packages for both
python 2 and python 3, using a pretty straightforward set of macros. See
spec files in the linked repository, and documentation on github.

So far this only reliably works on python 2 and 3. It can work with pypy
too, but pypy is not building so I can't test against it.

Now there is a number of remaining issues to be worked out, and I'd like
your feedback on them:
1. Necessary changes to OBS configuration
2. Backwards compatibility
3. Transition to new macros
4. New policies for d:l:py
5. Naming scheme


1. Necessary changes to OBS configuration
---
The macro set only works with the one particular repository, that has
the macros in its prjconf. In particular, the %python_module macro is
problematic, because it needs to be expanded *before* the build starts,
by OBS. Usually, we would put the macro definitions inside
/etc/rpm/macros.python, as a part of the python/python3/whichever
package, but that won't work in this case.

Before we can deploy these packages to Factory, either Factory's
prjconf, or OBS global config, needs to include at least the
%python_module macro.

And if possible, I'd like to include all of them, because:

2. Backwards compatibility
---
Basically, we would need to build for old distros using new macros.
There's a number of options:
a) macro definitions in OBS and everything will build everywhere
b) macro definitions in python, everything will build with new enough
version of python
c) macro definitions in prjconf of particular projects (say d:l:py),
only packages in those projects build.
Personally, i'd go with (a). And if that's not possible, with (b) and
(c) combined.

The problem with anything other than (a) is that it is going to be
difficult to write specs that work both with and without the macros. You
could conditionally include the %python_packages macro, but you would
have to shim all the others in every spec file, and that is going to be
ugly.
Which means that by using the new macros, we would be hard-forking the
python packages from ALL currently released distributions, unless we
could get the macro definitions into them.


Agreed, anything that is prjconfig related should apply to the Build
Service as a whole. Python code is really spread all over and having to
tell all project maintainers where ther might be a snippet of Python
that the prjconfig has to change and then making sure that any new
project that springs up gets the same treatment is too error prone.

Later,
Robert


--
Robert Schweikert MAY THE SOURCE BE WITH YOU
Public Cloud Architect LINUX
rjschwei@xxxxxxxx
IRC: robjo

< Previous Next >
List Navigation
References