[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensuse-packaging
Subject:    [opensuse-packaging] Re: New thoughts on python singlespec macros
From:       Todd Rme <toddrme2178 () gmail ! com>
Date:       2017-11-16 15:49:37
Message-ID: CADb7s=soJMrpTWjHTC+KgTaKjwLJRrjwWGmq4HoFFuGb-v2YdQ () mail ! gmail ! com
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]