Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #12942 > unrolled thread

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

Back to article view | Back to linux.debian.maint.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#972213: boost1.71: Please indicate some way which python versions you support Drew Parsons <dparsons@debian.org> - 2020-10-16 03:00 +0200
    Bug#972213: boost1.71: Please indicate some way which python versions you support Giovanni Mascellani <gio@debian.org> - 2020-10-16 08:50 +0200
      Bug#972213: boost1.71: Please indicate some way which python versions you support Drew Parsons <dparsons@debian.org> - 2020-10-16 10:50 +0200
        Bug#972213: boost1.71: Please indicate some way which python versions you support Alastair McKinstry <mckinstry@debian.org> - 2020-10-16 11:20 +0200

#12942 — 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

[toc] | [next] | [standalone]

#12943

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 <g.mascellani@gmail.com>

[toc] | [prev] | [next] | [standalone]

#12944

On 2020-10-16 14:43, Giovanni Mascellani wrote:
> Hi,
> 
> Il 16/10/20 02:53, Drew Parsons ha scritto:
>> 
>> Would it make sense to use the Built-Using [1] header?
...
>> [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".

Ah yes, I had a feeling there were more reasons to not prefer this 
method!


> 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.


That sounds like a useful approach.

The ecflow build could access the provided versions via
   dpkg -s libboost-python${BOOST_VERSION} | grep Provides

[toc] | [prev] | [next] | [standalone]

#12946

On 16/10/2020 09:19, Drew Parsons wrote:
> On 2020-10-16 14:43, Giovanni Mascellani wrote:
>> Hi,
>>
>> Il 16/10/20 02:53, Drew Parsons ha scritto:
>>>
>>> Would it make sense to use the Built-Using [1] header?
> ...
>>> [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".
>
> Ah yes, I had a feeling there were more reasons to not prefer this 
> method!
>
>
>> 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.
>
>
> That sounds like a useful approach.
>
> The ecflow build could access the provided versions via
>   dpkg -s libboost-python${BOOST_VERSION} | grep Provides

That works.

Code can be added that the package fails to rebuild if it can't get the 
necessary provides.

Thanks

Alastair

-- 
Alastair McKinstry, <alastair@sceal.ie>, <mckinstry@debian.org>, https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web