On Tue, Jun 13, 2017 at 10:52 AM, jan matejek
Fellow Python packagers,
while trying to solve the issues surrounding python3-only singlespec builds, I finally figured out that the OBS is not *at all* doing what I thought it was doing, and everything is now lost forever
and now seriously. For various technical reasons that I will discuss at the end of this e-mail, using "%undefine have_python2" for removing python2 from the build set is not viable. I will have to redesign the macros that are present in prjconf and use some other method to accomplish the same.
The current WIP solution is as follows:
1. %pythons macro will contain the build set, i.e., list of all flavors that we build for. in Factory, "%pythons" will expand to "python2 python3".
2. contents of %pythons will be conditional on %skip_python macros. If you "%define skip_python2 1" in the spec file, python2 will be removed from %pythons. the "%skip_python" symbols should not be defined ANYWHERE ELSE BUT the current spec file. For prjconf, it is more suitable to change contents of %pythons.
3. %python_module will iterate over %pythons, through a crazy convoluted scheme that Ruby is also using.
So for the end packager:
* if you want to build everything by distro defaults, nothing changes * if you want to *exclude* a particular flavor from the build, you "%define skip_$flavor 1" * if you want to list build flavors explicitly, you can redefine %pythons themselves: %define pythons python2 jython2 pypy3 * you can BuildRequire: %pythons, because %pythons will come from prjconf
For prjconf, we need:
* %pythons python2 python3 (This is an opportunity to mess things up, because the *last* item in %pythons actually specifies, through a side effect, the "default" python that overwrites conflicting files. If you specify "python3 python2" and then "%python3_only /usr/bin/foo", the /usr/bin/foo will actually be a python2 version. OTOH, this allows per-package customization of the default, and python-rpm-macros will contain the canonical order.) * the set of python_module expanders
Installed Python packages will still define %have_$flavor macros, so you can switch build options based on which pythons are present. However, this is no longer tied to the build set: especially in a local build, you could get %have_python2 true but not actually build it for Python2. That shouldn't matter in practice.
comments, questions, thoughts?
regards m.
-----
p.s.: For those interested, here are the technical details.
The original intention was that if you wanted to skip a particular build requirement, you could do: %undefine have_python2 This would remove "python2" from the build set and you wouldn't get any python2-related wording in the spec file.
One problem with this approach is that definitions in RPM are placed on a stack and so you need to %undefine as many times as you %defined. Hence the current bug where you need to %undefine have_python2 twice (at least).
Another is that OBS doesn't understand %undefine at all! So this declaration actually doesn't do anything, and your %python_modules still install *all* python versions. The double-%undefine is then needed because you get one have_python2 from prjconf and another from the installed python2 package.
The new solution doesn't rely on undefines, and redefinitions work about as well as we would expect.
Overall this seems good. The only issue with the current approach from what I can see is that it seems you can only add new pythons by completely replacing the default set. There doesn't seem to be a way to add individual non-default pythons while otherwise keeping the project defaults. This would be important for pypy or jython, where I think we would want to keep it disabled by default and only explicitly turn it on in a per-package basis. So perhaps a "%add_python foo" macro that adds "foo" to "%pythons" if it isn't already there. Perhaps by default it adds it to the beginning of the list if it isn't already there, while "%add_python foo 1" will always add it to the end of the list (promoting it to being the "primary" python version, even if it is already in "%pythons" at a different position). -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org