On 19/09/17 03:40, jan matejek wrote:
On 13.9.2017 17:18, Todd Rme wrote:
On Wed, Sep 13, 2017 at 7:42 AM, jan matejek
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 would have thought the better question is do we really need 2 versions of python applications 1 built with each, as a user of spyder or any other python app why would I care if its built with python2 or python3 as long as it works. When I was doing Qt app development as my day job I didn't care which version of Qt qtcreator was built with because it was independent of the version I was using, maybe all these apps not starting with python- should just build for whatever we determine is the default python version at the time, and then a macro could be used to change to only generating for one fixed version as specified by the macro ie if you wanted to temporarily keep building with python2 as python3 has issues. Then once those issues are fixed its just one flag in a macro to change. Currently all the python apps I maintain just build with python3 not using single spec, partly because they were migrated before single spec but also because there is no point in shipping 2 versions built with different versions of python. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B