Re: Questions on packaging with forked dependency
On Sun, Nov 24, 2024 at 07:46:58PM +0800, Eric Long wrote:
> 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.
Not a generic fix for this type of issue, the other reply already has the more
technical answer, and perhaps too obvious a suggestion but:
Is there any chance upstream for these crates would accept your changes for the
forked dependencies? You might have to wait for the changes to be accepted and
released, but it would simplify things on the packaging side.
Cheers,
Jelmer
Reply to: