Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




----- 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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux