Hi Drew (2024.08.24_14:56:07_+)
> > I pushed a git branch with a patch that adds this feature
> > (exclude_ext_rename), as I've already written it. But I don't think it's
> > a feature we need. So I don't intend to merge it.
>
> Fair enough for scipy. Across the broader python ecosystem it mi
On 2024-08-24 16:30, stefa...@debian.org wrote:
Hi Drew (2024.08.24_11:39:04_+)
Currently -X only applies to byte-compilation. The only way to do what
you want is --no-ext-rename, but that's all or nothing.
I think we can extend -X to apply to C extensions too...
Thinking about that some
Hi Drew (2024.08.24_11:39:04_+)
> Currently -X only applies to byte-compilation. The only way to do what
> you want is --no-ext-rename, but that's all or nothing.
>
> I think we can extend -X to apply to C extensions too...
Thinking about that some more, I actually don't see any point in this
Hi Drew (2024.08.23_21:51:41_+)
Currently -X only applies to byte-compilation. The only way to do what
you want is --no-ext-rename, but that's all or nothing.
I think we can extend -X to apply to C extensions too...
I could also imagine doing some magic to detect symbols in a shared
library
For the record, scipy PR#20321 is applied as commit 55849f7
https://github.com/scipy/scipy/commit/55849f7b9fe6bd7326e4447d05f3a5c40e76aa83
Package: dh-python
Version: 6.20240603
Severity: normal
I have a library package (scipy) which builds a shared library
(libsf_error_state.so)) used by the python code. This is a standard
.so shared library, not a python extension, so it shouldn't be renamed
with magic tags nor multiarch tuples. O
6 matches
Mail list logo
