Apps using default Python in Fedora vs. EPEL

[Toshio Kuratomi]

On Tue, Jan 27, 2015 at 10:50:07PM +1000, Nick Coghlan wrote:
> >
> > %if 0%{?fedora}
> > %global default_python python3
> > %else
> > %global default_python python
> > %endif
> 
> I'm wary of this proposed solution mostly due to the fact that in the
> middle of last year, the Beaker team had to go through and completely
> redesign the way the automatic kickstart generation worked, because
> the templates were full of checks that assumed "RHEL 6" as the default
> basis for derived distros. Once RHEL 7 and CentOS 7 were generally
> available, that assumption became problematically wrong (e.g. systemd
> wasn't a Fedora only feature any more), so the templates were all
> rewritten to be based on operating system feature flags instead (which
> had the added bonus of also making them more tolerant of Fedora
> derivatives).
> 
> I see the seeds of a similar problem being planted with the above
> proposal: what happens when, at some point in the future, "Python 3 as
> default" is no longer a Fedora-only feature? Do we have to go edit all
> the spec files again?
> 
Note that this ship has sailed long ago.  Fedora packaging spec style is
that someone (usually FPC) has to collect information about which
Fedora/RHEL version a feature became relevant and then construct
a conditional that accurately portrays that knowledge.  So in the example
above, at least a version check for fedora would be added.  When we are able
to build default python3 on rhel people would need to update spec files to
reflect that (but that's an EPEL branching event anyway so people are going to
have to do some manual work on to make the packages build on for the new
EPEL anyway.)

It would be good if we could do better, though....

> What if, instead, we were able to add a new macro that let folks
> *explicitly* opt in to running in the "system Python", but then define
> the recommended spec file usage such that it falls back to Python 2 if
> the "system Python" macro isn't defined?
> 
Slavek raises the issue of how we get this into the buildroot.  An idea
could be to talk to rel-eng and the other packagers about adding these sorts
of system-feature macros to a package in the buildroot.  We could create
a new package or add onto an existing one (is epel-release and
fedora-release in the buildroot?)  the package would contain a small set of
macros that specified certain features about the OS that packagers need to know 
Then we really could write the conditionals as a feature test instead of
a distro version test.

One drawback is that we would have to push the macros out to every release
that we build for (epel and fedora) otherwise we'd still have to use
distro+version  conditionals.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/python-devel/attachments/20150127/5fe21c8c/attachment.sig>