On Wed, Nov 18, 2015 at 5:27 AM, Neal Gompa <ngomp...@gmail.com> wrote: > On Wed, Nov 18, 2015 at 2:48 AM, Nick Coghlan <ncogh...@gmail.com> wrote: >> I'd been thinking using "pip install" instead of "setup.py install" in >> 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 module > 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 autogenerated deps. 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. -Toshio _______________________________________________ python-devel mailing list python-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
