> > 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.
there are in the order of the thousands python packages in Debian (let's guess-timate that half are pure-python, the remaining are extensions or depending on extensions), what i would prefer is a solution that doesnt require to modify (either by changing something or uploading the package) all of these packages by hand. i'll add it to python-cycler -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
