Define a default provider for python3-foo

[bnavigator]

My attempt at #69

[mcepl]

Thank you for this pull request, but I don’t like this variable. There should be just one source of wisdom on what’s the current provider, and that should be %primary_interpreter == 1 in the appropriate python*.spec file. We cannot read that macro, but we can find out what /usr/bin/python3 points to, and that should be the provider for python3-* packages. Not sure how to expand links in Lua (or with the RPM Lua macros, could stat(2) help?).

Perhaps something on this tune:

local sympython = "/usr/bin/python3"
local fullpath = io.popen("readlink -f '" .. sympython .. "'", 'r'):read('a')
fullpath = fullpath:gsub('[\n\r]*$','')
print(fullpath)

[bnavigator]

How about the latest commit? I went with a %#FLAVOR#_provides macro that expands some shell commands at runtime and checks for /usr/bin/pyhton?.

[mcepl]

Looking at https://bugzilla.suse.com/show_bug.cgi?id=1177477 and thinking “How do we deal with update-alternatives?”. Will we automatically switch all alternatives to default (not changing already non-default values) when changing the primary Python provider?

Also, things like python-tqdm which will have alternatives on something so obscure as /usr/share/bash-completion/completions/tqdm.

[bnavigator]

Sorry, I do not quite understand. How is this relevant to the primary provider during buildtime?

• /usr/bin/python3 is currently not under u-a control.
• This PR does not affect the current u-a priorities.

Do we need to increase the priority of the %python_install_alternative macro for the primary provider flavor?

[bnavigator]

Looking at https://bugzilla.suse.com/show_bug.cgi?id=1177477

I do not understand how that situation can occur with the current python36 and python38 packages in Tumbleweed.

[mcepl]

Looking at https://bugzilla.suse.com/show_bug.cgi?id=1177477

I do not understand how that situation can occur with the current python36 and python38 packages in Tumbleweed.

I don’t understand either, but I haven’t switched any system from python3.6 to python3.8 yet.

Actually, thinking about it, I don’t think we have ever had python36-* packages in TW.

[bnavigator]

Sidenote: I noticed a few days ago that Ubuntu has sitelib in python3 rather than python3.X so all flavors use the same sitelib and populate the cache with files for their version.

[scarabeusiv]

Yep we won't be changing to Debian layout. This layout we have is used among all rpm distros and it would not help us if users could not inject rpms from Fedora if they really need so.

Debian world has a common folder for the python and specify just minimal supported and thats it.

[bnavigator]

It was just a sidenote ;)

[mcepl]

OK, please, rebase this PR, and I will happily merge it. Thank you!

[bnavigator]

Done.