Re: rust-*/librust-* arch:any vs. arch:all and cross-compilation support
Hi Jonas,
On Fri, Sep 27, 2024 at 05:36:37PM +0200, Jonas Smedegaard wrote:
> Quoting Helmut Grohne (2023-02-20 19:43:52)
> > lintian does not have the full picture. It looks at one source package
> > plus all of its binary packages in isolation. It cannot see the
> > multi-arch annotations of dependencies. Hence the multi-arch hinter was
> > added as an extra component outside lintian. On the flip side, the
> > hinter could do the flagging that you suggest here. In essence, it could
> > flag all packages satisfying all of the following conditions:
> > * Architecture: all
> > * Multi-Arch: foreign
> > * Package: librust*-dev
> > * Depends: some package that is not m-a:foreign
> >
> > We can actually express this in SQL:
> >
> > SELECT name
> > FROM indeppackage AS i
> > WHERE name LIKE 'librust%-dev'
> > AND multiarch = 'foreign'
> > AND EXISTS (SELECT 1 FROM archdepcandidate AS c WHERE c.dependerid = i.id);
>
> Can the above be refined to ignore dependency packages not m-a:foreign
> which are named librust-*?
No.
> ...because as I understand it those pose no problem here, they are just
> using bogus hinting for convenience reason.
We cannot tell whether those rust libraries are not M-A:foreign for
convenience or for a technical reason. Therefore, we must be
conservative and assume that a package that declares itself to be
architecture-dependent actually is architecture-dependent.
Examples:
* librust-pq-sys-dev
* librust-soup3-sys-dev
* librust-x11-dev
* librust-xkbcommon-dev
* librust-yaml-dev
* librust-zstd-sys-dev
If any of these (and many more) shows up in your dependency tree at any
spot, a Multi-Arch: foreign declaration of a rust library becomes an rc
bug.
Hence, the suggested rule of thumb is that rust libraries generally must
not be marked Multi-Arch: foreign unless all of its dependencies are
already marked Multi-Arch: foreign. Does that make sense to you now?
> If convenience-hinting packages can be omitted (assuming I correctly
> understood the reasoning for doing so), then yes, I would find it
> beneficial to have such action item on tracker.d.o.
I am not sure what you are referring to when you say
"convenience-hinting". I don't think any of the hints are convenience.
Helmut
Reply to: