Re: Bug#972213: boost1.71: Please indicate some way which python versions you support
On 15/10/2020 08:13, Giovanni Mascellani wrote: Hi, Il 14/10/20 15:52, Alastair McKinstry ha scritto: I maintain the package "ecflow" which uses libboost-python-dev. Now with the transition to python3.9, ecflow will support (where possible) multiple python versions. Currently it supports python3.8 but not python3.9 ; this may be fixed in a binNMU or next version, but I cannot tell whether my failure to build python3.9 support for ecflow is due to missing py3.9 support in boost, or a bug in my packaging. BTW, a binNMU was just requested to add Python 3.9 support. Can some mechanism be added to enable tracability ? In general, Boost supports all the Python versions currently supported by the Python team, except that someone has to file a binNMU for them to appear once a new Python version is packaged. To check which Python versions are supported by a specific package version, it is enough to check the content of the libboost-python1.71.0 package (replace 1.71.0 with future versions where applicable): $ dpkg -L libboost-python1.71.0 | grep libboost_python /usr/lib/x86_64-linux-gnu/libboost_python38.so.1.71.0 /usr/lib/x86_64-linux-gnu/libboost_python39.so.1.71.0 (until yesterday you did not have the python39 variant) Does this answer your question? Giovanni. Not really. This is probably better discussed on debian-python. The point was that there is a lack of a good mechanism to see which packages provide py39 support, etc. In principle my package ecflow just needs a rebuild after the boost is rebuilt, but tracking if this actually works, or add a particular dependency to enable automatic rebuild/tracking. Alastair -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#972213: boost1.71: Please indicate some way which python versions you support
Source: boost1.71 Followup-For: Bug #972213 X-Debbugs-Cc: debian-python@lists.debian.org Would it make sense to use the Built-Using [1] header? e.g. Built-Using: python3.8 python3.9 dh_python3 knows if the module includes extensions (*_python*.so.) and could inject the pythons into Built-Using. dh_golang does something like this for the Go packages. There's a nuance which I don't fully understand about the intended use of Built-Using, which means it's not really the proper solution for the Go packages. I think that's related to the fact that Go applications are statically linked. The Python extensions are dynamically linked so maybe Built-Using could work fine. [1] https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using
Re: Bug#972213: boost1.71: Please indicate some way which python versions you support
Hi, Il 16/10/20 02:53, Drew Parsons ha scritto: > Source: boost1.71 > Followup-For: Bug #972213 > X-Debbugs-Cc: debian-python@lists.debian.org > > Would it make sense to use the Built-Using [1] header? > e.g. > Built-Using: python3.8 python3.9 > > dh_python3 knows if the module includes extensions > (*_python*.so.) and could inject the pythons into Built-Using. > > [...] > > [1] > https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using The precise web page you are linking hints that this use of Built-Using would be improper: "This field should be used only when there are license or DFSG requirements to retain the referenced source packages. It should not be added solely as a way to locate packages that need to be rebuilt against newer versions of their build dependencies". That said, I forgot to mention that the Python versions Boost is compiled against is also tracked in the package names provided by libboost-python1.71.0, which are currently libboost-python1.71.0-py38 and libboost-python1.71-py39. Is this better? More in general, there can be dozens of ways to advertise which Python versions are used to build Boost.Python, but it is not clear to me how this information should be consumed. Giovanni. -- Giovanni Mascellani
