On Wed, Nov 15, 2017 at 12:04 PM, jan matejek <jmatejek@suse.com> wrote:
On 15.11.2017 16:45, Todd Rme wrote:
On Wed, Nov 15, 2017 at 9:43 AM, jan matejek <jmatejek@suse.com> wrote:
python2 builds are disabled. Ideally I would like to see "%{python2_module foo}" and "%{python3_module foo}" that will only pull in that dependency if that version of python is being used. This also has the advantage of not needing to care about backwards-compatibility issues of "python-foo" vs. "python2-foo" names, which is handled inconsistently right now. If that is not feasible, just having a reliable check would be an improvement.
The issue with "BuildRequires: %python2_module" is that you can't put empty string in place of %python2_module. We'd need to have something like %python2_buildrequires, but that sounds too specific and impractical.
Would it be possible to replace disabled requires with some dummy package that is a buildrequires by default anyway?
python-rpm-macros for instance? :) That's certainly possible, although rather kludgey. It would solve the inconsistency. OTOH another possible inconsistency is when python2 version requires something that doesn't start with "python-". That's why I like guard conditions better.
Yes, the guard conditions would still be needed. The reason I like the approach is because it fits well with the existing pattern, where "%python_foo" is the multi-python version, "%python2_foo" is the python2 version, and "%python3_foo". There are only a couple cases where this pattern doesn't hold.
Can the macros move "_build.$flavor" to "build" during the corresponding part of "python_expand"?
That is precisely what happens. The problems you see exist because the *other* versions are lying around. An alternate solution would be to hide the directories better. I'm not sure where though.
What about moving it into buildroot? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org