Import Rust vendoring document

[slyon]

Importing the "RustCodeInMain" wiki page and transforming it to Markdown: https://wiki.ubuntu.com/RustCodeInMain

Also updating the README.md file to reference the documentation around the dh-cargo tooling.

Fixes #65

[slyon]

CC @liushuyu @schopin-pro @samkamer -- Please let me know if you're fine with this move of the page.

[schopin-pro]

Is this documentation rendered anywhere?

[slyon]

Is this documentation rendered anywhere?

Only through GitHub, e.g.: https://github.com/slyon/ubuntu-mir/blob/rust-vendoring/vendoring/Rust.md

[setharnold]

lgtm with a quick nit and an open question. Thanks

[setharnold]

It'd be nice to update this link when appropriate, how do we remember to do that?

[slyon]

The link points to some historical reference, why do you think we should update this? IMO, we should rather re-write our Rust MIR rules (for doing less vendoring) and drop this reference eventually.

We can use this PR for discussing such improvements, but I have the impression we're not yet at a point where we can enforce non-vendored Rust packages. Somebody (Foundations/Toolchain?) still need to lay the groundwork of having a set of core packages available, i.e. as suggested in #35

[slyon]

Actually, I wonder if we should still enforce the vendoring mandate, today. Maybe we should still ALLOW for vendoring Rust crates, but allow package maintainers to use the librust-*-dev packages from the archive, too. That way we could gradually move away from the vendoring, especially for Rust dependencies that are considered to be stable by the package maintainers. And run a proper MIR process on those selected rust-* source packages.

@liushuyu Do you think this would be feasible already, or is the Rust ecosystem still moving too fast?

This would mean we need to also adopt the corresponding section in the README: "The rust ecosystem currently isn't yet considered stable enough for classic lib dependencies and transitions in main; therefore the expectation for those packages is to vendor (and own/test) all dependencies (except those provided by the rust runtime itself)."

[jbicha]

I believe vendoring directly to vendor/ will cause problems for any packages that are using debian/source/format 3.0 (quilt) where it's not allowed to directly touch things outside of debian/ except via patches or similar.

For gnome-snapshot, I used the Debian Policy § 4.16 convention of using debian/missing-sources\ instead.

So the commands to create and update the vendoring are:

rm -rf debian/missing-sources/
cargo vendor debian/missing-sources
git add -f debian/missing-sources # to avoid missing files because of .gitignore
git commit -m "Vendor Rust crate build dependencies into debian/missing-sources/"

Add a patch like this:

diff --git a/.cargo/config b/.cargo/config
new file mode 100644
index 0000000..8c56c72
--- /dev/null
+++ b/.cargo/config
@@ -0,0 +1,5 @@
+[source.crates-io]
+replace-with = "debian"
+
+[source.debian]
+directory = "debian/missing-sources"

[jbicha]

I documented gnome-snapshot's vendoring workflow at https://salsa.debian.org/ubuntu-dev-team/snapshot/-/blob/ubuntu/latest/debian/README.source

[liushuyu]

I believe vendoring directly to vendor/ will cause problems for any packages that are using debian/source/format 3.0 (quilt) where it's not allowed to directly touch things outside of debian/ except via patches or similar.

Maybe we can take a page from Node.js, where you can have another source package <name>.orig-vendor.tar.xz. Some other Rust packages are doing this way instead.

[slyon]

Maybe we can take a page from Node.js, where you can have another source package <name>.orig-vendor.tar.xz. Some other Rust packages are doing this way instead.

@liushuyu I really like this approach. Could you provide an example of such a Rust package and describe how it's being done?

A similar approach of a vendoring .orig tarball has also been suggested by others in the past, e.g.: https://blog.shadura.me/2020/12/22/vendoring-rust-in-debian-derivative/

[schopin-pro]

s390-tools uses that approach.

…

On Tue, 17 Sept 2024, 12:08 Lukas Märdian, ***@***.***> wrote: Maybe we can take a page from Node.js, where you can have another source package <name>.orig-vendor.tar.xz. Some other Rust packages are doing this way instead. @liushuyu <https://github.com/liushuyu> I really like this approach. Could you provide an example of such a Rust package and describe how it's being done? — Reply to this email directly, view it on GitHub <#66 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUXZP7I2NAPT3U2WSA446L3ZW75SJAVCNFSM6AAAAABNR2CPJSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJVGE3DKOJRGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>