Le 12/07/2024 à 10:35, Jonas Smedegaard a écrit :
Hi Birger,
Quoting Birger Schacht (2024-07-12 08:17:12)
On 7/11/24 9:55 PM, Jonas Smedegaard wrote:
Quoting Philipp Kern (2024-07-11 21:13:42)
I'd - at the very least - would like to see a statement why a fork is
necessary. Innovation can happen in forks. But they don't necessarily
need to be in the archive to make a point.
dh-cargo is designed to repackage prepackaged code projects already
distributed through crates.io. If you do an NMU where you include the
preferred form for distribution, you are kindly asked to stop doing
NMUs because that messes with how the Rust team deliberately avoids
tracking the actual source for the code projects distributed.
I listed in the ITP a list of features lacking in dh-cargo, which I need
for packaging Rust-based code projects in Debian from preferred form for
distribution source. I do not need all of the features for all of them,
but some of them sometimes.
This still does not answer the question why a fork is the better option
instead of working with the people behind dh-cargo to integrate those
features into the codebase?
I have tried but failed to work closely with the Rust team. It was a
painful experience, and I would prefer not to elaborate in public.
I nowadays work only loosely with the Rust team: To the extend that they
use the Debian bugtracker, we coordinate our packaging efforts there,
and my patches for their tooling have been publicly available for the
past two years, where I have maintained it structured so as to be
easy for them to cherry-pick back into dh-cargo/cargo as much as they
might find relevant, at the cost of my use of it being cumbersome, and
the code not really inviting for more innovative changes.
I didn't know that you were making patches easy to be cherry-picked.
I would have tried otherwise
The Rust team has chosen to not cherry-pick any of my patches into their
tooling. I have not strongly pushed for that, and expect strong
pushback if I tried:
I would be happy to take all your patches that makes sense.
We should try to avoid code duplication and adding more complexity to Debian.
Cheers,
Sylvestre
