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
--============== 40523035131512411=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmaQ6sYACgkQLHwxRsGg ASHLpQ//TY48iNkQyPDYTqkw+/YPVgVZycUDWALY7ImqOVqhaLbN/1Zy03kK/G0R URZs5BveSxaV0UMPp75S3k5YyVC2xmQ5Z09TDWNjzwNiMX6rBwx2SCHtbUS7eTXh sll6lz8Pzi+62kBKi4Cr2DAY7ZpYb/LGdx5PL0+iQa4l6LGV7KxC72T8j3yznXs3 oqv50AwXYyqb4afEGHZvGstHUhEB+WHi3ekwX6ts9YY3WLrcbf0KcBWt4ZXCHRj5 1BrDI6SDFD4pYyZHVnKrtxprvV1A2ufiRFxewc9QZfnhI4ZVHwOJNMKuCxQ3BnKl NW6P90IVEYJZn3xXN9H/I42BEhOoa83M5BS7NgE21kHjBeDqObx3KgfABbJCfr64 Acyl/VXhrz1Y0/w4uhTwZVP9wneFSUez62ddUkdrWsH75YL7Kr0pds10dRqUCDBG 3CC4h6HBJLKtSyxRsiTEMPhkQxNrq2MO8g9trJB8