----- Original Message -----
From: "Pavel Raiskup" praiskup@redhat.com To: devel@lists.fedoraproject.org Sent: Thursday, October 4, 2018 1:05:47 PM Subject: Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly
On Thu, Jan 11, 2018 at 01:02:32PM -0800, Troy Dawson wrote: I'll say it once again, but why can't we just have %{python2_available} and %{python3_available} macros defined in the base system?
And once again, what about %py3_build_expected? Proposed in https://bugzilla.redhat.com/show_bug.cgi?id=1636020
The most obvious argument against that is that it is not 100% bullet proof to cover all Fedora Python packages. But I don't think it is a problem in particular; there are _many_ (maybe the most of them) python packages that could use this.
Pavel _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
This boils down again to having the same SPEC for a bunch of different branches which I personally dislike, especially for branches that could be ~10 years apart. My main argument against it, is that having a clean SPEC file, which could differ slightly between branches, is a lot cleaner than having a huge %if spaghetti.
However, again this is more of a personal preference and I can totally understand that having the same SPEC eases the maintainers' burden by a big margin, our time and resources are not limitless.
Having said that, providing more macros (and maintaining them and take care of all the edge cases), is also a burden for those who implement them. I'd like at least FPC to weigh in for that and if the benefits provided by those macros, would benefit a big chunk of our packagers then I'm all for it. If it would be only though for enabling fast forward merges for some cases, instead of cherry-picking I'd be reluctant to do that.