Quoting Helmut Grohne (2024-09-27 18:24:48) > 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. I worried that would be your response. > > ...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. Understood. > 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? Yes, The rule of thumb makes sense to me. Now as well as in 2023. > > 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. Sorry, confusingly phrased on my part. I mean this: Quoting Helmut Grohne (2023-02-20 18:12:14) > Technically, not all packages need to become arch:any+m-a:same. As you > correctly observed, the problem arises from non-rust dependencies in the > dependency tree. For instance, librust-typenum-dev has no dependencies. So more accurately I mean convenience-arch:any(+m-a:same) - i.e. packaging arch:all code as arch:any and as a consequence hinting as is required for arch:any packages, as a convenience simplification of by default doing arch:all+m-a:foreign and only when needed doing the arch:any+m-a:same workaround. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature