----- Original Message ----- > 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.
I'll try to find out what it'd take to add such a package to epel minimal buildroot and fedora minimal buildroot and we'll see. I actually have one more use case for this and that is the Py3 in EPEL, where having some macros in minimal buildroot would help a lot, too. I'll try to find out ASAP and post the result here. Slavek > Regards, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Regards, Slavek Kabrda _______________________________________________ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
