On Wed, Nov 18, 2015 at 11:32 AM, Toshio Kuratomi <a.bad...@gmail.com> wrote: > > 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
Based on the feedback from you guys, I've made the changes to move to pythonX.Ydist() in the dependency generator. That code has been submitted as a pull request to the RPM GitHub repository[0]. I also added a switch for those who want pythonXdist() Provides, but it is opt-in rather than opt-out. The option is only for distributions that intend to carry only one Python runtime per major version. I've built a new package with the changes requested in my Copr repository[1]. The new package is called "rpm-depgen-pythondistdeps" and it obsoletes the older "rpm-depgen-pythoneggs" package. A "dnf update" should get it, but if not, just do "dnf install rpm-depgen-pythondistdeps" and it will do the rest. [0]: https://github.com/rpm-software-management/rpm/pull/33 [1]: https://copr.fedoraproject.org/coprs/ngompa/rpm-depgen-pythoneggs/ -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ python-devel mailing list python-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
