On Nov 17, 2015 8:18 AM, "Neal Gompa" <ngompa13@gmail.com> wrote:
>
> I see the problem you are describing, but how do you solve it currently?
>
Currently we use manually specified dependencies with package names here.  So when python2.6-foo is built, the packager specifies a dependency on python2.6-setuptools. 

> That said, I *think* I could autogenerate Provides for pythonX.Ydist(M)
> and pythonXdist(M), while only having requires generated
> with pythonX.Ydist(M). Would that solve the problem while allowing
> BuildRequires using pythonXdist(M) to pick up the latest one? I'm not
> entirely sure it would...
>
Nope. In the spec you would need both major and minor to make auto generated dependencies work correctly in all circumstances.

If your particular distribution only shipped a single version of python2 and a single version of python 3 on that distribution you could use pythonXdist but the packages would break on other distributions that shipped multiple runtimes.

Something to consider: if you're worried about how to specify manual deps in the spec file portably it may be best to continue using package names there.  That way built packages take advantage of the auto dep generator in most cases, most packagers can specify buildrequires using the generic package name that's stable across distro releases (and sometimes across distros) and truly special cases can pin a specific compatible runtime by manually specifying pythonX.Ydist(foo).

Also, if doing it this way makes the pythonXdist unnecessary it would be nice to leave it out.  The size of yum metadata is a big bottleneck.  I believe someone once enabled erlang auto deps that increased the size so much that we (fedora) removed that auto dep generator from our packaging (overriding the maintainer).  It feels like an even worse problem these days when the packageset is bigger and dnf is downloading the full filelist.

-Toshio