On Wed, Nov 18, 2015 at 5:27 AM, Neal Gompa <ngompa13(a)gmail.com> wrote:
On Wed, Nov 18, 2015 at 2:48 AM, Nick Coghlan
> I'd been thinking using "pip install" instead of "setup.py
> the build macros would be sufficient, but I now realise that isn't the
> case - if a project uses flit (for example) as its build utility, then
> we're going to need to generate a suitable BuildRequires in pyp2rpm
> and similar tools (perhaps using the "BuidlRequires:
> pythonX.Ydist(flit)" format). The build macros themselves could still
> delegate the task of working out the right build command to invoke to
> pip, though.
The main issue I see with that is how to make it so that python upgrades
aren't obnoxiously painful. If BuildRequires use pythonXdist(module) format,
but all *generated* runtime requirements use pythonX.Ydist(module) format,
this problem goes away. But as Toshio mentioned, how do we solve that in a
multi-version environment (like Enterprise Linux, for instance)?
Really, for this I think continuing to use package names is the right
thing to do. Package names uniquely identify the package built for
the default python version for that distribution+release which is what
we want to make rebuilding a package on a newer release with a newer
version of python as the default. Attempting to build this into the
generated dependencies duplicates the features that relying on the
name gives us.
Using pythonX.Ydist(module) for BuildRequires effectively locks the
to a specific Python version until each and every maintainer upgrades them.
That is an awful thing to have to do, and no other programming environment
in any RPM-based distribution requires that. Most of the time, this is an
unnecessary burden on the package maintainers.
Note: we do want this when we're specifically building a package for a
non-default version of python. If we want to have python2.7 in EPEL6
or python2.6 in Fedora24 or (python3.5 and python3.4 for that matter),
then the package stack built for that non-default python needs to
specify that the packages it requires also need to be those built for
that stack. So all of those packages can BuildRequire the X.Y
It's for the default stack that we want to have some notion of
"default" within the dependencies
My view on pythonXdist(module) vs pythonX.Ydist(module) for
BuildRequires is that DNF/Zypper may actually solve this issue for us.
Perhaps presenting it with pythonXdist(module) and a package that provides
the appropriate "python(ABI) = X.Y" as part of the builddep grab will actually
pick the right one (after all, each module would Require a specific
"python(ABI)" anyway). I'm not sure if Yum would do the same, though
(I hope it does!). I suppose the key is whether or not the depsolver analyzes
the whole request before creating its proposed transaction, rather than
iteratively solving and presenting the results.
No depsolver should solve this in its core code. it's a special case
that relies on information and decisions outside of the package deps'
literal meanings. Making the special case mandatory would definitely
lead to issues. For instance, say python-foo ships a utility along
with its library and there is no python3-foo. python3-bar requires
the utility to build. If dnf is made to only satisfy the dep if the
package also matches on python(abi) then this will not be buildable
because the depsolver is trying to be too smart instead of doing what
the packager told it to do.