workspaces: overzealous native library dependency conflicting

[nagisa]

Problem

I have a workspace with multiple crates, but for brevity purposes, consider this workspace:

[workspace]
members = [
    "brand_new",
    "old_rusty",
]

These two output a binary executable and don’t depend on each other at all. They have the following dependencies:

brand_new: ring v0.16
old_rusty: ring v0.13

And both versions of ring, in turn, specify links="ring-asm".

Trying to cargo update this workspace will then fail with the following error:

error: failed to select a version for `ring`.
    ... required by package `brand_new v0.0.1 (/tmp/foo/brand_new)`
versions that meet the requirements `^0.16` are: 0.16.11, 0.16.10, 0.16.9, 0.16.7, 0.16.6, 0.16.5, 0.16.4, 0.16.3, 0.16.2, 0.16.1, 0.16.0

the package `ring` links to the native library `ring-asm`, but it conflicts with a previous package which links to `ring-asm` as well:
package `ring v0.13.5`
    ... which is depended on by `old_rusty v0.0.1 (/tmp/foo/old_rusty)`

failed to select a version for `ring` which could resolve this conflict

There's no actual conflict here, however, and not using a workspace would make it work just fine. Whether that’s a good-enough of a workaround is dubious, though.

Steps

1. Copy the setup from this gist: https://gist.github.com/nagisa/ca95a787c25ba27a73eb3662c85016b2
2. Run cargo update

Possible Solution(s)

Do not conflict when a particular workspace crate links to just one links dependency. Care must be taken, however, to ensure that we still do conflict when we’d end up pulling multiple links crates into the same binary.

Notes

Output of cargo version: not relevant

[ehuss]

Consolidating some similar reports of links and workspaces:

#8550: A duplicate in a dev-dependency causes an error with another crate.

#8636: Independent build-dependencies collision.

[jonas-schievink]

I've also run into this issue in knurling-rs/defmt#426, where I tried to support multiple incompatible versions of a library by means of Cargo features. It seems that it is impossible to do so because of this bug, which makes upgrading that library very painful (the whole ecosystem needs to do so in a coordinated fashion, and it requires a breaking change in every single downstream library).

[nagisa]

I think the defmt issue is similar, but ultimately quite different. This issue is entirely about two different, independent, workspace members each having a different links-conflicting crate in their dependency tree conflicting despite not having any reason to conflict.

A single crate depending (optionally) on two links-conflicting crates feels much less clear cut to me.

[Sytten]

We are facing a similar issue on SeaQL/sea-query#388 where we have two different packages depending on two versions on sqlite and it fails to build. This is very annoying because like it is mentioned above the whole ecosystem needs to keep in sync for us to be able to upgrade even though the dependencies have nothing in common.