singlespec RFC: python3-only builds, %have_python, %skip_python

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

singlespec RFC: python3-only builds, %have_python, %skip_python

jan matejek-4
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.


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: singlespec RFC: python3-only builds, %have_python, %skip_python

Adrian Schröter
Hi Jan,

On Dienstag, 13. Juni 2017, 16:52:45 CEST wrote 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

do I want to know more? ;)

> 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?

I think it is a valid solution when you want to enable/disable python version builds
per project or repository.

Just for reference, here is an example where one spec file builds for both python
worlds in parallel. It is IMHO a good solution when you want to sort out it per python
package:

 https://build.opensuse.org/package/view_file/home:adrianSuSE:branches:science:unstable/python3-pyside2/python-pyside2.spec?expand=1

Note: The @BUILD_FLAVOR@ will be set by OBS based on the _multibuild file.

The main package is excluded here and two sub packages are building.
Check the build state box here:

 https://build.opensuse.org/package/show/home:adrianSuSE:branches:science:unstable/python3-pyside2:python-pyside2


...
> Another is that OBS doesn't understand %undefine at all! So this declaration actually doesn't do

this is actually a rpm limitation ;)

> 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.
>


--

Adrian Schroeter
email: [hidden email]

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
 
Maxfeldstraße 5                        
90409 Nürnberg
Germany


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: singlespec RFC: python3-only builds, %have_python, %skip_python

jan matejek-5


On 13.6.2017 16:58, Adrian Schröter wrote:
>> Another is that OBS doesn't understand %undefine at all! So this declaration actually doesn't do
>
> this is actually a rpm limitation ;)

RPM understands %undefine just fine ... for some values of "fine" anyway ;)

But for the purpose of expanding BuildRequires, OBS is running its own spec parser
(build/Build/Rpm.py) and that supports %define but not %undefine. At least as far as I was able to
figure out; this also closely matches the observation that OBS's macro expansion step behaves very
differently from everything else.

regards
m.


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: singlespec RFC: python3-only builds, %have_python, %skip_python

Thomas Schraitle-3
In reply to this post by jan matejek-4
Hi Jan,

> [...]
> 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:
> [...]
> comments, questions, thoughts?

Thanks Jan for all your efforts!

Are these nice and fancy topics documented somewhere? ;)


--
Gruß/Regards,
    Thomas Schraitle

----------------------------------------------------------------------
SUSE LINUX GmbH              (o<  
Maxfeldstrasse 5             /\\      Documentation Specialist
90409 Nuernberg, Germany    _\_v      http://www.suse.com
http://lizards.opensuse.org/author/thomas-schraitle/
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton,
    HRB 21284 (AG Nürnberg)

attachment0 (180 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: singlespec RFC: python3-only builds, %have_python, %skip_python

todd rme
In reply to this post by jan matejek-4
On Tue, Jun 13, 2017 at 10:52 AM, jan matejek <[hidden email]> wrote:

> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: singlespec RFC: python3-only builds, %have_python, %skip_python

Luigi Baldoni
In reply to this post by jan matejek-4
jan matejek-4 wrote
and everything is now lost forever
That bad, huh? ;)

comments, questions, thoughts?
Two questions:
  * Will python_module() have to be defined differently in python3-only specfiles?
  * Any chance it can be transformed into a macro and moved to the prjconf?
    It's kind of impossible to remember.

Regards
Reply | Threaded
Open this post in threaded view
|

Re: singlespec RFC: python3-only builds, %have_python, %skip_python

Sebastian-2
In reply to this post by jan matejek-4
Thanks for all your efforts!

Could you add these explanations to the existing wiki page please?
Where in the specfile do I need to define %skip_python2?
Do you have a working example? I tried to fix d:l:py/mypy but it didn't
work out (same errors as before).

Sebastian

--
python programming - mail server - photo - video - https://sebix.at
cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers



signature.asc (871 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: singlespec RFC: python3-only builds, %have_python, %skip_python

jan matejek-4
hello,

On 15.6.2017 16:40, Sebastian wrote:
> Thanks for all your efforts!
>
> Could you add these explanations to the existing wiki page please?
> Where in the specfile do I need to define %skip_python2?
> Do you have a working example? I tried to fix d:l:py/mypy but it didn't
> work out (same errors as before).

this is a proposal!
nothing about this works just yet! :)
i'll let you (and the list) know when this is deployed.

m.

>
> Sebastian
>

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: singlespec RFC: python3-only builds, %have_python, %skip_python

jan matejek-4
In reply to this post by Luigi Baldoni
hi,

On 14.6.2017 21:15, Luigi Baldoni wrote:
> Two questions:
>   * Will python_module() have to be defined differently in python3-only
> specfiles?
>   * Any chance it can be transformed into a macro and moved to the prjconf?
>     It's kind of impossible to remember.

You can transfer it to prjconf in your own projects :)

The reason for the redefinition in spec is that we can't modify prjconfs of released distros.
In d:l:py, we could add the macros everywhere, but then you'd get specs that fail to build in other
projects. That's not desirable.

I'm looking into modifying Leap's prjconf, but I'm not sure if it is a good idea to add untested
things this close to a release.

So. For now, if you want a package for anything other than Tumbleweed, then you need to keep the
redefinition, and yes, you need to modify it for a python3-only package.

m.


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: singlespec RFC: python3-only builds, %have_python, %skip_python

jan matejek-4
In reply to this post by todd rme
On 14.6.2017 18:14, Todd Rme wrote:
> 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.

True, but unlikely to be fixed.
OBS's limited macro processing when evaluating buildrequires probably wouldn't run anything remotely
as clever as you're proposing...

But it doesn't matter, because of dependencies.
It doesn't make much sense to make an individual package supporting "system pythons + jython",
because then the package's jython dependencies wouldn't be satisfied. Adding jython to the buildset
is something suitable on project level. And on project level, we can afford to change the buildset
once in a blue moon if the distro buildset changes...

On project level, you could also add the "have_python" condition, and then allow individual packages
to "%define have_jython 1" to only build some of them and not the whole project. This is what is
done with pypy3 right now: the pypy3 interpreter doesn't build, but you can %define have_pypy3 in
your spec today and you get build instructions for pypy3.

regards
m.

> 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).



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: singlespec RFC: python3-only builds, %have_python, %skip_python

Sebastian-2
In reply to this post by jan matejek-4
Hi,

I used the new approach for python-typed-ast and unfortunately I now I
get this build error:

[   54s] found conflict of python-typed-ast-1.0.4-2.1.x86_64 with python3-typed-ast-1.0.4-2.1.x86_64:
for all distros.

Sebastian

https://build.opensuse.org/package/show/devel%3Alanguages%3Apython/python-typed-ast



On 06/15/2017 04:46 PM, jan matejek wrote:

> hello,
>
> On 15.6.2017 16:40, Sebastian wrote:
>> Thanks for all your efforts!
>>
>> Could you add these explanations to the existing wiki page please?
>> Where in the specfile do I need to define %skip_python2?
>> Do you have a working example? I tried to fix d:l:py/mypy but it didn't
>> work out (same errors as before).
> this is a proposal!
> nothing about this works just yet! :)
> i'll let you (and the list) know when this is deployed.
>
> m.
>
>> Sebastian
>>
--
python programming - mail server - photo - video - https://sebix.at
cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers



signature.asc (871 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: singlespec RFC: python3-only builds, %have_python, %skip_python

Luigi Baldoni
   Hi,
as of today, even with %define python_module() python3-%{**} and %define skip_python2 1
my python3-only module is still trying to create both a python- and a python3- package.

But speaking of the change to the default, is the known header:

%{?!python_module:%define python_module() python-%{**} python3-%{**}}

supposed to become:

%{?!python_module:%define python_module() python2-%{**} python3-%{**}}

or even:

%{?!python_module:%define python_module() python2-%{**} python-%{**}}

now ?

Regards
Reply | Threaded
Open this post in threaded view
|

Re: singlespec RFC: python3-only builds, %have_python, %skip_python

jan matejek-4
On 29.6.2017 11:29, Luigi Baldoni wrote:
>    Hi,
> as of today, even with %define python_module() python3-%{**} and %define
> skip_python2 1
> my python3-only module is still trying to create both a python- and a> python3- package.

hm, let's see which three new bugs were introduced by squashing the previous one.

>
> But speaking of the change to the default, is the known header:
>
> %{?!python_module:%define python_module() python-%{**} python3-%{**}}
>
> supposed to become:
>
> %{?!python_module:%define python_module() python2-%{**} python3-%{**}}

definitely not!

this header applies only for old distributions. Anything based on today's TW will have a definition
of %python_module coming from prjconf and this line will not execute.

Old distributions have python-foo for python2, python3-foo for python3. Do not mess with
compatibility line.
;)

(if you don't plan on supporting Leap 42.x, you can drop this line entirely)

regards
m.


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: singlespec RFC: python3-only builds, %have_python, %skip_python

Luigi Baldoni
jan matejek-4 wrote
On 29.6.2017 11:29, Luigi Baldoni wrote:

> But speaking of the change to the default, is the known header:
> supposed to become:
>

definitely not!

this header applies only for old distributions. Anything based on today's TW will have a definition
of %python_module coming from prjconf and this line will not execute.
Good to know. But what about python3-only packages? Will anything have to be redefined in TW?

And what of openstack python modules? The ones that were about to supply a Provides: python2-foo
in each.
This kind of throws a wrench in the works. Unification doesn't seem imminent there, what's the best
option, in your opinion?

Regards
Reply | Threaded
Open this post in threaded view
|

Re: singlespec RFC: python3-only builds, %have_python, %skip_python

jan matejek-4
On 29.6.2017 13:46, Luigi Baldoni wrote:
> Good to know. But what about python3-only packages? Will anything have to be
> redefined in TW?

the TW definition recognizes "skip_python", so no. this is designed to work as is.

>
> And what of openstack python modules? The ones that were about to supply a
> Provides: python2-foo
> in each.
> This kind of throws a wrench in the works. Unification doesn't seem imminent
> there, what's the best
> option, in your opinion?

well, I could really use input from people who actually work on OpenStack.

But this seems unrelated? If OpenStack packages can't work on python3, that is a problem that
OpenStack needs to solve ASAP?

m.


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: singlespec RFC: python3-only builds, %have_python, %skip_python

Luigi Baldoni
jan matejek-4 wrote
On 29.6.2017 13:46, Luigi Baldoni wrote:
> Good to know. But what about python3-only packages? Will anything have to be
> redefined in TW?

the TW definition recognizes "skip_python", so no. this is designed to work as is.
Excellent

jan matejek-4 wrote
> And what of openstack python modules? The ones that were about to supply a
> Provides: python2-foo
> in each.
> This kind of throws a wrench in the works. Unification doesn't seem imminent
> there, what's the best
> option, in your opinion?

well, I could really use input from people who actually work on OpenStack.

But this seems unrelated? If OpenStack packages can't work on python3, that is a problem that
OpenStack needs to solve ASAP?
They have meetings every (well, almost) Thursday in #openstack-meeting-alt
at 12:00 UTC if you wish to partake.

Regards
Reply | Threaded
Open this post in threaded view
|

Re: singlespec RFC: python3-only builds, %have_python, %skip_python

jan matejek-4
In reply to this post by jan matejek-4
hello,
as of today, the new macros are live in Factory, documented on the wiki page, and Sebastian's
python-typed-ast bug is also resolved in d:l:py.
(still present in factory, I'll submit the updated python-rpm-macros later today)

regards
m.

On 13.6.2017 16:52, jan matejek wrote:

> 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.
>


signature.asc (849 bytes) Download Attachment