Different build dependency for the same dependency target, Why?

Hello :slight_smile: ,

A little bit of context:
I was trying to create a port of sendxmpp-rs tagged v2.0.0 for FreeBSD.
The build failed because a bug fixed on rsutc-version but...

On the master branch of the sendxmpp project I have this:

sendxmpp-rs on ī‚  master is šŸ“¦ v2.0.0 via šŸ¦€ v1.59.0
āÆ cargo tree --invert rustc_version
rustc_version v0.3.3
[build-dependencies]
ā””ā”€ā”€ tokio-xmpp v3.0.0
    ā””ā”€ā”€ sendxmpp v2.0.0 (/usr/home/rollniak/sources/sendxmpp-rs)

If I checkout to the tags v2.0.0 the we see the problem:

sendxmpp-rs on ī‚  master is šŸ“¦ v2.0.0 via šŸ¦€ v1.59.0
āÆ git checkout tags/v2.0.0
Note: switching to 'tags/v2.0.0'.

sendxmpp-rs on ī‚  HEAD (062571c) is šŸ“¦ v2.0.0 via šŸ¦€ v1.59.0
āÆ cargo tree --invert rustc_version
rustc_version v0.3.2
[build-dependencies]
ā””ā”€ā”€ tokio-xmpp v3.0.0
    ā””ā”€ā”€ sendxmpp v2.0.0 (/usr/home/rollniak/sources/sendxmpp-rs)

I don't understand why the version of rustc_version in build dependence is not the same between master and tags/v2.0.0 event if tokio-xmpp v3.0.0 is requested in both case.

If someone can enlight the newcomer I'm, I will be grateful :slight_smile: .

sendxmpp-rs is a binary application, so as is standard for non-library rust apps, it packages Cargo.lock in version control. This effectively makes all dependency versions part of the deliverable, and part of what's released in a version tag like 2.0.0. Cargo.lock locks in exact versions of all libraries involved in the build process, so when you checkout the v2.0.0 release, you're also checking out the lock file - and dependencies - used for that release.

Versions are only updated to the latest compatible release when Cargo.lock isn't present, or when cargo update is used.

This helps with build reproducibility, and provides another safeguard against released apps failing to build if a breaking change is accidentally introduced without an appropriate version bump in a dependency. It has the disadvantage of not auto-including dependency updates automatically, but the advantage of reproducibility, and usually (for non-build dependencies) a binary crate should release a new version to include critical dependency updates anyways since all regular libraries will be statically linked into built binaries. Not the case here, but it runs into this problem.

To manually build a version of this application with the code from v2.0.0, but updated dependencies, checkout v2.0.0 then run cargo update before compiling. Or to just update rustc-version, I believe you can use cargo update -p rustc-version

Thanks you for your explanation and clarity. :smiley:

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.