On Thu, Sep 24, 2026 at 09:48:57PM +0530, Nilesh Patra wrote: > On 24/09/26 8:55 pm, Alexandre Detiste wrote: > > Package: lintian > > Version: 2.141.0 > > Severity: important > > > > Dear Lintian Maintainers, > > > > To avoind needlessy pulling in python3-pip & python3-setuptools > > in ever single flit run, the engine "python3-flit" has been spun-out. > > > > Please rework lintian to check for "python3-flit | flit" instead of "flit". > It currently checks for flit:any. I initially thought I could just add > python3-flit:any > and that would just work but I saw python3-flit is not marked `M-A: foreign`. > > I suspect depends on setuptools is the reason for that? In that case :any > should be simply > skipped, right?
I am somewhat confused here. :any only ever makes sense if the target package carries "Multi-Arch: allowed". Neither flit nor python3-flit have that Multi-Arch value. So both python3-flit:any and flit:any would be universally unsatisfiable. flit is expressly meant for pure Python modules (those that don't ship C sources). As such its behavior can largely be assumed architecture-independent. Beyond this, python3-flit is a pure Python module with no architecture-dependent dependencies. The flit package contains the flit CLI and even if it uses architecture-dependent modules (e.g. python3-charset-normalizer), its CLI interface also likely is architecture-independent. As such I think that both packages should be marked Multi-Arch: foreign. (This is confirming what Alexandre replied, but also asking for the other annotation.) >From a multiarch pov, I concur with the package split #1148412. It is what enables this marking. In the pre-split way, we could not sensibly mark flit Multi-Arch: foreign, because we could not tell that e.g. python3-requests was a CLI dependency rather than a library dependency. After the split, we can tell and mark both. I recognize that the original motivation for splitting was not multiarch, but clarity and also concur with that aspect. Helmut
