On 05. 11. 19 19:41, Kevin Kofler wrote:
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,
I oppose this change, because this is yet another size increase:
It is a trade. Performance vs. size. Some use cases will not gain more
performance, but most will. Some use cases will be affected by the size
increase, but mos won't. Details below.
That said, it is a fair point. When Fedora decides whether to do this, this
needs to be considered.
As a negative side effect, when both libpython3.8.so and
/usr/bin/python3.8 are installed, the filesystem footprint will be
slightly increased (libpython3.8.so on Python 3.8.0, x86_64 is ~3.4M).
and while:
OTOH only a very small amount of packages will depend on
libpython3.8.so.
in practice, that does not help because some of those packages are installed
by default, e.g., the ones you mentioned being installed by default even on
the Docker image:
*'''libcomps'''
*'''libdnf'''
*'''vim'''
I haven't checked vim (but work can be done to get rid of the dependency, it is
vim-minimal -> libpython). For the dnf stack, is is mostly a matter of adapting
the cmake files to not link extension modules to libpython. An example:
https://src.fedoraproject.org/rpms/libarcus/pull-request/8
Not being able to make the packages listed in bold libpython-less is a problem
that would activate the contingency plan (revert).
but there are more, such as gdb, libreoffice, krita, boost, etc. that are
installed on various live images, and calamares, which is popular on
remixes. So all those images will be bloated as a result of your code
duplicating change.
gdb Python support is optional.
krita is IMHO big enough to not notice the filesize increase.
So is libreoffice, but in fact only libreoffice-pyuno is doing this and it might
be adapted or the dependency of libreoffice on libreoffice-pyuno might be made
optional.
For boost, only the Python modules are affected and I'm confident it's the same
problem as in the most of the rest of the list.
Extension modules should not link to libpython. Packages need to be adapted.
Only applications embedding Python need to link to libpython. That is what
software like krita or blender are most likely doing.
In addition:
By applying this change, libpython's namespace will be separated from
Python's, so '''C extension which are still linked to libpython'''
might experience side effects or break.
so compatibility is an issue too.
It is an issue. We will look into this issue and provide help fixing the
affected software. Python extension modules should not link to libpython and the
packages need to be adapted not to do that.
Only Python extension modules that embed Python will truly be problematic to handle.
--
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
