Oh, sorry, I didn't look at the user name :)
Could you please expand on what you have written here?
I'm not sure I follow you entirely.
----- Original Message -----
From: "Neal Gompa" <ngompa13(a)gmail.com>
To: "Development discussions related to Fedora"
Sent: Friday, July 1, 2016 5:43:46 PM
Subject: Re: F25 System Wide Change: Automatic Provides for Python RPM Packages
On Fri, Jul 1, 2016 at 8:34 AM, Tomas Orsava <torsava(a)redhat.com> wrote:
I'm sorry, I could have expanded on it.
The difference is that if we enable --majorver-provides than there's no way
we can ship more than one Minor version per a Major version .
With macros, however, we have no problem shipping two minor versions, and
the macros will continue to work, pointing to the one we treat as the
main/default one. We can then also create macros for the additional minor
version as well.
 "The option '--majorver-provides' is intended for use
if only one Python stack per major version will be
available at a given time, as unexpected results may
occur if there are multiple independent Python stacks
per major version available." 
Yes, I wrote that comment.
The "unexpected" behavior in question is that if you have more than
one stack and you don't have some other constraint, the depsolver
could consider it an equal provider and install the wrong version of
the module for the version of python you want to use to build your
software/package. IMO, if the "python(abi)" requirement is matched
everywhere, it should function no differently than how it does today
when we do builds/rebuilds from one python version to the next. It's
probably worth testing to be sure, though...
The generated dependencies will all be major+minor specific, though.
You'll also probably want to enforce that the dep generator uses
python3 (as I did in my backport testing package), since it uses
the unversioned python shebang by default.
真実はいつも一つ！/ Always, there's only one truth!
devel mailing list