Re: Bug#972213: boost1.71: Please indicate some way which python versions you support

2020-10-15 Thread Giovanni Mascellani
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 



Bug#972213: boost1.71: Please indicate some way which python versions you support

2020-10-15 Thread Drew Parsons
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

2020-10-15 Thread Alastair McKinstry

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.