On Tue, Aug 23, 2016 at 9:47 AM, jan matejek
On 22.8.2016 20:21, Todd Rme wrote:
Also there is an interesting technical dilemma with this syntax: either %if_cpython2 means "if cpython2 is in the buildset", or "if the following piece of code applies to the cpython2 subpackage". These are very different in the requires/filelist context:
This was intended for the latter case. I can't think of a situation where it would be useful for one python variant to know that some other python variant is also being built. I thought the whole idea was to keep them separate.
The problem becomes apparent when you want a spec file that can build for "all available pythons". You might want to include instructions in %build that apply to python3 only, and you might want the spec file to pass even when python3 is not in the build set.
I am still not clear why, for example, the python2 build would need to know whether a python 3 build is happening. At least my thinking was that if a spec file is not going to be built against python3, for example, any python3-specific macros would just be skipped.
BuildRequires: %py_buildrequires
With my current approach this doesn't seem useful at all? Either you use %{python_module foo} to get module for all pythons that are in %have_flavor, or you can list the buildrequires explicitly.
Some buildrequires are only relevant, or only available, for certain python variants. So there needs to be some way to specify buildrequires on a per-variant basis. You could wrap them in an %if_foo clause, but that seems much more verbose to me.
BuildRequires are common for the whole spec file. All of them must be present. Say you have a package that needs %flavor-setuptools and %flavor-nose for all %flavors, but pypy-featuresupport for pypy only, and python3-legacy-prints for python3 only:
That is only true if all supported variants are being built. My thinking was that the whole point of being able to define, for example, %have_cpy2, is to be able to disable that build option without having to modify the rest of the spec file. That way it would be easy for projects to apply a patch to single line in a spec file to disable variants they don't care about. That made me think of another point. Would it be possible to make the %have_foo macros wrap %bcond_with and %bcond_without to be able to easily override it at build time? That way individual projects could even more easily disable particular python variants. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org