Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

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

 



On Tuesday, November 12, 2019 6:18:00 AM MST Miro Hrončok wrote:
> On 12. 11. 19 14:00, Miroslav Suchý wrote:
> 
> > Dne 05. 11. 19 v 16:03 Ben Cotton napsal(a):
> > 
> >> == Summary ==
> >> Python 3 traditionally in Fedora was built with a shared library
> >> libpython3.?.so and the final binary was dynamically linked against
> >> that shared library. This change is about creating the static library
> >> and linking the final python3 binary against it, as it provides
> >> significant performance improvement, up to 27% depending on the
> >> workload. The static library will not be shipped. The shared library
> >> will continue to exist in a separate subpackage. In essence, python3
> >> will no longer depend on libpython.
> > 
> > 
> > It seems that we have one group of people who prefer speed and another
> > group of  people who prefer saved space.
> > 
> > Instead of focusing on a swiss-knife to satisfy everybody (which will not
> > work),  can we have python3-static **and** python3-dynamic (*) packages
> > and let users decide which one will be installed and handle
> > `/usr/bin/python3` using `alternatives(8)`?
> > Then FESCO can "only" decide which one will be the default. And that is
> > far less  controversial than deciding whether you will be forced to use
> > a time-saving or space-saving solution.
> 
> 
> While I realize that this might actually be a clever thing to do, as the
> Python  maintainer, I don't want this for various reasons. Most
> importantly, it means we need to to "support" twice that many Python
> interpreters.
> 
> It would also create a problem in RPM requirements.
> 
> Suppose a package need /usr/bin/python3.8 to be dynamically linked. How do I
>  express that? It would need to harcode some kind of
> /usr/libexec/python3.8-dynamic? Would this require custom shebangs... etc.?
> I  really don't want to go that way. It's bad on RHEL 8 already, with
> "platform-python".
> 
> Note that this is my personal opinion, not a team opinion.
> 
> -- 
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> Archives:
> https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx

If that software was to be packaged, in this case, you'd simply:
Requires: python3

change the shebang to /path/to/my/python3

However, I believe there's a third option here. It could be as simple as 
providing a python3-static in addition, and NOT using `alternatives`. This 
way, packages and scripts that actually need the performance improvements can 
directly call python3-static, and everything else just continues to work as it 
does now.

-- 
John M. Harris, Jr.
Splentity

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
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