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

[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"

[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: ***@***.***>

[slyon]

I've added an example of how s390-tools uses a .orig-vendor.tar.xz approach to isolate the Rust crates in a separate .orig tarball, keeping the gnome-snapshot (using debian/missing-sources) and authd (native + Rust/Golang vendoring) examples around for reference.

This PR should now be ready for merging if others agree!