Re: Questions on packaging with forked dependency
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
Reply to: