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. 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: The added functionality relates to ideologically conflicting views on what is the source of a Rust project and what is really the purpose of Debian. As an example, Rust team tooling includes debian/patches in the binary package as part of a design principle to mimick crates.io code distribution as closely as possible. Another example is that Rust team tooling can only treat a single crate located in the root as source, not a crate in a subdirectory or multiple crates in what is called a "workspace" in Cargo lingo, again because crates.io always redistributes code as single crates, regardless of how the code was developed, i.e. the preferred form for upstream development. After two years of not trying to convince the Rust team that their ideology is flawed, but practicing another approach to Rust packaging, depmonstrating that e.g. multi-crate workspaces are possible to treat as Debian source for multiple Debian binary packages, and offering publicly my patches easily adoptable if they wanted to, I have shifted to make my patches into a proper fork of their tooling, making it much easier for the little team now working on it to maintain and develop further, including tracking bugs in it which was close to impossible for the past two years of it being copied into each and every Debian package needing it. The cost of this shift is that the codebase is no longer as easy to merge back into the Rust team tooling - not because we want to steal from them or punish them, but just as a side-effect of this shift. Hope that clarifies. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
