----- Original Message -----
> From: "Pavel Raiskup" <prais...@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-le...@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
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
