On 28 January 2015 at 03:32, Toshio Kuratomi <a.bad...@gmail.com> wrote: > On Tue, Jan 27, 2015 at 10:50:07PM +1000, Nick Coghlan wrote: >> 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.
That sounds vaguely analogous to the situation we have in Beaker: adding completely new "system features" may require a Beaker server update, while enabling and disabling already known features for a custom distro is just a configuration setting for that distro in the database. Actually switching to that model required updating the base templates for every distro we natively support. The reason we decided that approach was worth the extra up front effort was because it meant we just had one place to update in the future (the code that handles the calculation of the distro -> feature mappings) rather than having to search the templates for all the cases where we were switching based on the distro. I personally think "do it right" (i.e. figuring out how to enable feature based rather than version based checks) is the direction we should go for Fedora & EPEL, and then Slavek & I can separately tackle the challenge of getting key downstreams (i.e. RHEL & CentOS) to go along with that change. I'm more optimistic than Slavek is about that, as many of the reasons we made the change for the Beaker kickstart templates also apply to building for different environments. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel