Hi Jonas,
On Mon, Feb 20, 2023 at 06:44:23PM +0100, Jonas Smedegaard wrote:
> I don't see a need for such general rule for all librust-*-dev packages.
This definitely is a trade-off. Hence I asked about what we should do
about it.
> E.g. librust-futures-timer-dev and librust-event-listener-dev has no
> dependencies so should be safe to distribute as arch-all and marked as
> m-a:foreign, right?
Yeah, I mentioned librust-typenum-dev earlier and you found more. I
expect that there are probably hundreds of pure rust libraries without
dependencies. Really, the only reason to not have them arch:all is
mitigating the risk of changing dependency trees.
> Sure, there is a theoretical risk that some day in the future those
> packages grow dependencies that require changing that, but isn't that
> the case generally for m-a hinting?
You are entirely correct about this. It definitely is a heuristic.
> I guess it makes sense instead to have a lintian warning for packages
> marked m-a:foreign that all its dependencies are equally marked (or if
> that's unreasonably expensive then check only one level deep). That
> should help flag misuses of m-a:foreign including this one of mine (for
> most but not all the librust-*-dev packages that I maintain).
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);
I guess you're also interested in the output of the query.
librust-crdts-dev
librust-ahash-dev
librust-assert-json-diff-dev
librust-async-attributes-dev
librust-async-channel-dev
librust-async-executor-dev
librust-async-fs-dev
librust-async-net-dev
librust-async-process-dev
librust-async-std-dev
librust-blocking-dev
librust-femme-dev
librust-flume-dev
librust-hyper-rustls-dev
librust-kv-log-macro-dev
librust-lazy-regex-dev
librust-leptonica-plumbing-dev
librust-leptonica-sys-dev
librust-nom-locate-dev
librust-oxilangtag-dev
librust-resource-proof-dev
librust-rustls-native-certs-dev
librust-rusty-pool-dev
librust-serde-fmt-dev
librust-smol-dev
librust-socks-dev
librust-tesseract-plumbing-dev
librust-tesseract-sys-dev
librust-test-case-dev
librust-version-sync-dev
librust-criterion-dev
librust-oxhttp-dev
librust-oxiri-dev
librust-retry-dev
librust-rustls-dev
librust-xor-name-dev
librust-nanorand-dev
librust-threadfin-dev
librust-ahash-0.7-dev
librust-criterion-0.3-dev
librust-isahc-dev
librust-ureq-dev
As a confirmation of Fabian's observation, this list includes
librust-serde-fmt-dev. Note that this is not transitive yet. After
fixing these, some reverse dependencies will be added to the list. Also
note that running this query on delfin.d.o cannot be easily done by DDs
yet, because the underlying sqlite database uses wal mode. Sorry about
that.
Should the hinter generate reverse hints for these and thus issue action
items on tracker.d.o?
Helmut
