----- Original Message ----- > From: "Pavel Raiskup" <praiskup@xxxxxxxxxx> > To: devel@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx > 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. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx