`cargo tree -d` skips dups shown by `--target all` but that impact current target

[ydirson]

Problem

In upcoming xen-guest-agent 0.3.0, running the build on x86_64-unknown-linux-gnu platform, checked with both 1.72.0 and 1.74.1:

user@work-vates:xen-guest-agent (main >)$ cargo tree -d
libloading v0.7.4
└── clang-sys v1.6.1
    └── bindgen v0.69.1
        [build-dependencies]
        └── xenstore-sys v0.1.4
            └── xenstore-rs v0.5.0
                └── xen-guest-agent v0.3.0 (/home/user/src/xen-guest-agent)

libloading v0.8.1
└── xenstore-rs v0.5.0 (*)

but:

user@work-vates:xen-guest-agent (main >)$ cargo tree -d --target all
bitflags v1.3.2
└── redox_syscall v0.4.1
    └── parking_lot_core v0.9.9
        └── parking_lot v0.12.1
            └── tokio v1.35.0
                ├── netlink-proto v0.11.2
                │   ├── rtnetlink v0.14.0
                │   │   └── xen-guest-agent v0.3.0 (/home/user/src/xen-guest-agent)
                │   └── xen-guest-agent v0.3.0 (/home/user/src/xen-guest-agent)
                ├── netlink-sys v0.8.5
                │   ├── netlink-proto v0.11.2 (*)
                │   └── rtnetlink v0.14.0 (*)
                ├── rtnetlink v0.14.0 (*)
                └── xen-guest-agent v0.3.0 (/home/user/src/xen-guest-agent)

bitflags v2.4.1
├── bindgen v0.69.1
│   [build-dependencies]
│   └── xenstore-sys v0.1.4
│       └── xenstore-rs v0.5.0
│           └── xen-guest-agent v0.3.0 (/home/user/src/xen-guest-agent)
├── nix v0.27.1
│   └── rtnetlink v0.14.0 (*)
├── rustix v0.38.28
│   ├── is-terminal v0.4.9
│   │   └── env_logger v0.10.1
│   │       └── xen-guest-agent v0.3.0 (/home/user/src/xen-guest-agent)
│   └── which v4.4.2
│       └── bindgen v0.69.1 (*)
└── sysctl v0.5.5
    └── xen-guest-agent v0.3.0 (/home/user/src/xen-guest-agent)

libloading v0.7.4
└── clang-sys v1.6.1
    └── bindgen v0.69.1 (*)

libloading v0.8.1
└── xenstore-rs v0.5.0 (*)

(snipping windows crates)

Relevant crate dependencies are:

[dependencies]
tokio = { version = "1.25.0", features = ["full"] }
netlink-proto = { version = "0.11.2", optional = true }
rtnetlink = { version = "0.14.0", optional = true }

[features]
default = [..., "net_netlink"]
net_netlink = ["dep:netlink-proto", "dep:netlink-packet-core", "dep:netlink-packet-route", "dep:rtnetlink"]

That is, tokio is a mandatory dep, and netlink is pulled by a default feature, regardless of target.

It seems their pulling of bitflags v1 should really appear

Steps

1. clone https://gitlab.com/xen-project/xen-guest-agent/
2. run above-listed commands

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.74.1 (ecb9851af 2023-10-18)
release: 1.74.1
commit-hash: ecb9851afd3095e988daaa35a48bc7f3cb748e04
commit-date: 2023-10-18
host: x86_64-unknown-linux-gnu
libgit2: 1.7.1 (sys:0.18.0 vendored)
libcurl: 8.4.0-DEV (sys:0.4.68+curl-8.4.0 vendored ssl:OpenSSL/1.1.1u)
ssl: OpenSSL 1.1.1u  30 May 2023
os: Debian 12 (bookworm) [64-bit]

[ehuss]

Sorry, I'm not understanding what this issue is about. Can you also say what you are expecting it to do and why?

The reason bitflags is showing up with --target all is because parking_lot_core pulls in redox_syscall on the redox operating system, and that pulls in the older 1.x version of bitflags.

[ydirson]

The reason bitflags is showing up with --target all is because parking_lot_core pulls in redox_syscall on the redox operating system, and that pulls in the older 1.x version of bitflags.

Oh OK - that's not very visible, and I admit I had not checked whether it was actually built on my setup.

So it's not a bug - but then it shows it could be useful, when using --target all, to show which target causes a given crate to be included in the tree. Would that be better in a new feature ticket, or would it be OK to retarget this one ?

[weihanglo]

So it's not a bug - but then it shows it could be useful, when using --target all, to show which target causes a given crate to be included in the tree. Would that be better in a new feature ticket, or would it be OK to retarget this one ?

That option could fit in the existing --edges option as a new kind, but would be a bit difficult to show the information. Platform specific dependencies could be pulled by a combination of cfg matched, not only target platform triples. We can just show the raw cfg(…) from the dependency, though I am not sure if it looks better. Need someone to experiment ideas around it.