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.