[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: