Questions on packaging with forked dependency
Hi all on debian-rust,
I'm trying to package one of my Rust project (non-crates.io) for
practice, which contains several forked dependency on GitHub that I made
some downstream changes. But as I went on vendoring these
[source."git+https://...";] dependencies, I realized they contain other
dependencies that are available in Debian, but it's an outdated version
that seems hard to bump to the newest due to other packages depending on
this older version (even in crates.io).
I can't partially replacing [source.crates-io] in .cargo/config.toml
with my own vendored directory, so I'm thinking about a hybrid of what
Rust and GNOME teams are currently doing, but I wonder which way is the
best:
1) vendor the forked dependencies only in d/missing-sources (or other
name), and bump the Debian version of all outdated crates.io
dependencies (possibly with heavy patching on build rdepends) to match
them. This way we only need to add `[source."git+https://...";]
replace_with = "..."` in config.toml.
2) vendor the forked dependencies as well as its newer dependencies in
d/missing-sources, leaving others available in Debian as Build-Depends,
and patch the vendored crates and make their dependencies point to {
path = "../<name>" } otherwise. I wonder if I can use d/patches to patch
debian/, though.
3) similar to 2), but instead put vendored crates in another orig
tarball (.orig-vendored-deps.tar.gz), and patch them similarly in d/patches.
4) do what GNOME teams are currently doing -- vendor every dependency in
d/missing-sources.
Personally I favor 3), but I'm curious to see if anyone has other
opinions or better ideas.
Cheers,
Eric
Reply to: