Hi Alexandre, Sorry for having missed this earlier and thanks to Stefano for poking me.
On Wed, Aug 14, 2024 at 01:59:54PM +0200, Alexandre Detiste wrote: > Can you confirm ? I do confirm that it is sensible and useful to mark python3-urllib3 M-A:foreign. Stefano also asked me to iterate on why we need such chanegs. Python modules tend to turn up in Build-Depends here and there. An Arch:all Python module generally becomes unsatisfiable in cross builds. A simple change that makes it satisfiable is annotating it M-A:foreign as is being requested here. That explains why it is useful to perform such marking. The tricky part is figuring out whether M-A:foreign actually is correct. In particular, M-A:foreign must not be applied if the module has a transitive dependency on a Python extension module. If it were thus marked and a non-native Python interpreter were used, the pure Python module dependency were considered satisfied and it would transitively require the native extension that is of no use to the non-native Python interpreter. In this analysis, we disregard extensions of the stdlib as those are included with the interpreter and thus match its architecture. So when there is no transitive dependency on any Python extension, we tend to ask for the module to be marked M-A:foreign. If there is such an extension, instead we ask for the pure Python module to be changed to Arch:all + M-A:same. Hope this clarifies. Helmut
