On Wed, Nov 18, 2015 at 11:32 AM, Toshio Kuratomi <a.badger(a)gmail.com> wrote:
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 <ncoghlan(a)gmail.com> wrote:
>> 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 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
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. 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. 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.
真実はいつも一つ！/ Always, there's only one truth!