On Fri, Jul 1, 2016 at 8:34 AM, Tomas Orsava <tors...@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 [0]. > > 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. > > > [0] "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." [1] >
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[1]), since it uses the unversioned python shebang by default. [1]: https://copr.fedorainfracloud.org/coprs/ngompa/rpm-depgen-pythondistdeps/ -- 真実はいつも一つ！/ Always, there's only one truth! -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
