Hi Sandro, On Fri, Dec 20, 2019 at 12:38:10AM -0500, Sandro Tosi wrote: > > pymvpa2 fails to satisfy its cross Build-Depends, because its dependency > > on python-cycler is unsatisfiable. python-cycler is a Python module that > > on what arch specifically? i cant find any BD-uninstallable arch at > https://buildd.debian.org/status/package.php?p=pymvpa2&suite=unstable > that's due to python-cycler.
Likely on any architecture, but I only checked on amd64. The buildd pages only list native satisfiability though. Refer to https://qa.debian.org/dose/debcheck/src/pymvpa2.html to also see cross builds. That view is kinda limited though as it only displays one random of many problems. It often makes sense to also check https://bootstrap.debian.net/cross_all/pymvpa2.html. Only then you spot python-cycler. python-cycler is one of many reasons here. > i'd really like not to add this m-a tag tbh I think we need to talk about this. You didn't give a reasons for why you dislike it. Let me give my reasons for doing it to avoid more back and forth. There is prior art. A fair number of python modules in Architecture: all packages (around 100) are already tagged Multi-Arch: foreign. Notable examples include python3-six, python3-pkg-resources and python3-distutils. Why would you want python modules to be inconsistently maintained? We're not adding such marking for the fun of it. There is a concrete underlying problem being solved. If you don't like my solution, can you think of a different solution to the underlying problem? You can get an overview of non-temporary satisfiability issues in unstable at https://bootstrap.debian.net/cross_all.html (huge html). You'll find lots of satisfiability issues involve python modules. I agree that sometimes marking modules Multi-Arch: foreign can be wrong (e.g. for extension modules or modules that have a dependency on an extension module), but why not use the easy solution when it is available? Please treat python-cycler as an example instance of a problem class here. It really affects very many packages and we want a solution that is acceptable to many packages. Beware that we may end up changing around 1000 packages to fully solve this, so we better get this right. Helmut
