Re: Questions on packaging with forked dependency

[Eric Long <i@hack3r.moe>]

On 24/11/2024 20:34, Matthias Geiger wrote:
> 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
>
>

Hi Matthias,

This really clears up my mind, thanks!

I was looking at librsvg, which do vendor all of its Rust dependencies. 
I could only guess it's for historical reasons.

I am getting my changes upstream, but if they are unresponsive for too 
long, or can't be worked around in my own code, I would publish my 
modified version to crates.io. That leaves another question: does 
packaging libraries have requirements on statistics or other metrics 
(e.g. download count, dependents)? In other words, could my forked 
version of library get into Debian, along with my said project? 
Definitely will try my best to upstream, though.

Cheers,
Eric

(sorry about the previous one that goes off-list)