Re: Bug#972213: boost1.71: Please indicate some way which python versions you support
On 10/15/20 10:03 PM, Alastair McKinstry wrote:
> 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.
I don't think that packages should care about that at all. It usually is only
an issue when adding a new python version, and this happens once in a year. The
transition tracker [1] provides a guidance how to build stuff in which order,
based on dependencies, but doesn't take care about build-dependencies,
autopkgtest dependencies, and dependency cycles. And binNMUing 600 packages
takes time ...
Matthias
[1] https://release.debian.org/transitions/html/python3.9.html
Reply to: