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]
[1]
https://github.com/rpm-software-management/rpm/commit/29abb07fbf6b9ea255bd26e492c104eac8d2370f
On 07/01/2016 02:23 PM, Neal Gompa wrote:
On Fri, Jul 1, 2016 at 2:48 AM, Tomas Orsava <tors...@redhat.com> wrote:
Hi Neal!
I believe you will be able to use a macro for that so that dependencies are not
tied to specific minor versions. I.e. something like:
(Build)Requires: python%{python3_version}dist(somemodule)
Of course that isn't very neat, so maybe 2 macros could be provided that would
work thus:
(Build)Requires: %python2dist somemodule
(Build)Requires: %python3dist somemodule
That would solve the issue but still allow Fedora to possibly ship 2 different
minor versions of Python 3 for example.
What makes that different from just enabling the --majorver-provides
and allowing people to use "python3dist(somemodule)" or
"python2dist(somemodule)"?
That said, it's not out of the question to be able to work that way,
as Ruby works similarly in openSUSE (since their system allows them to
support more than one version of ruby in parallel if they want) and
libraries work that way in Mageia.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
