Re: Questions on packaging with forked dependency

[Matthias Geiger <werdahias@riseup.net>]

Am 24.11.24 um 12:46 schrieb Eric Long:
> 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
Hi Eric,

note that vendoring should be avoided unless there is a very good reason 
not to. For partial vendoring you can take a look at [0]. This requires 
you to use the wrapper in d/rules.

(This is one of three packages in the GNOME team that actually uses 
vendored code.)

Otherwise, I can only recommend getting your changes upstreamed or 
re-publishing as re-named crate. iirc having the same name for a crate 
does not work and you run into conflicts because you might end up 
pulling in crate foo

which you already have vendored at a lower version locally. You could 
vendor all packages; however this will likely not be an official Debian 
package then.

You can try if the wrapper approach with partial vendoring works (since 
afaik it's the only way to build "mixed"); I'd urge you to get your 
changes upstream though. If this is to become an official Debian package 
vendoring should

really be avoided unless absolutely needed.


best,


werdahias


[0] 
https://salsa.debian.org/gnome-team/shortwave/-/blob/debian/latest/debian/rules?ref_type=heads#L23