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

List:       opensuse-packaging
Subject:    [opensuse-packaging] Re: Packaging python singlespec applications
From:       jan matejek <jmatejek () suse ! com>
Date:       2017-09-18 18:10:19
Message-ID: 559b3804-e0bd-fa9f-5720-b09a7010c513 () suse ! com
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


On 13.9.2017 17:18, Todd Rme wrote:
> On Wed, Sep 13, 2017 at 7:42 AM, jan matejek <jmatejek@suse.com> wrote:
>> hello,
>>
>> On 12.9.2017 21:28, Todd Rme wrote:
>>> First, it would be nice if %python_subpackages allowed us to specify
>>> additional packages to manage. These would be packages named using
>>> "%package -n foo" that we nevertheless want to have multiple versions
>>> of. The macros would then create a set of packages
>>> "foo-%{python_bin_suffix}". So for example we might say
>>> %{python_subpackages spyder}. If we did that, we would get
>>> "spyder-3.6" and "spyder-2.7", with Requires, Provides, Obsoletes, and
>>> %files all handled appropriately for the given python version.
>>
>> I kind of like this, but don't quite understand how you would use it.
>> You're presuming the package is called "spyder"? or "python-spyder"? what is the subpackage here?
> 
> So you would still have "Name: python-spyder" that would be handled
> normally (although it might not have a %files section).  There would
> be a subpackage  "%package -n spyder". The "spyder" %package,
> %description, %files, etc. would be replaced by
> "spyder-%{python2_bin_suffix}" and "spyder-%{python3_bin_suffix}".

Why is the master package called "python-spyder"?

Wouldn't it be better, in this case, to change the logic for packages that aren't called "python-foo"?
Like, "python-foo" converts to "python2-foo" and "python3-foo"
whereas "spyder" converts to "spyder-2.7" and "spyder-3.7"
?

Is there a usecase where we want both of these behaviors?
If yes, maybe this should be done by a single option switch to %python_subpackages.

I do have the vague idea that more explicit control of %python_subpackages is desirable, but ISTM i
don't have enough usecases yet to formulate how that would work.

> Let's use python-numpy as an example. My understanding is that at
> preprocessing time something like "%files %{python_files}" is
> converted to, for example, "%files -n python3-numpy". My idea is that
> something like "%files %{python_files -f foo.bar}" would be converted
> to "%files -n python3-numpy -f foo-%{python3_bin_suffix}.bar". So it
> would still be done at the preprocessing stage, as only the file name
> would need to be edited.  The actual file contents would be handled by
> the normal %files macro.

That's certainly possible, but what if the actual file contents need to be modified?
In the most common usecase, I expect that the generated file would contain results for all flavors
rolled together.

...of course, we can add what you're suggesting in the meantime and leave the modification question
to the %install section as-is

regards
m.


["signature.asc" (application/pgp-signature)]
-- 
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]