----- Original Message -----
From: "Pavel Raiskup" <praiskup(a)redhat.com>
To: devel(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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.
--
Regards,
Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat