Hi Johannes, Quoting Johannes Schauer Marin Rodrigues (2024-07-11 19:47:42) > Quoting Jonas Smedegaard (2024-07-11 18:06:21) > > Package: wnpp > > Severity: wishlist > > Owner: Jonas Smedegaard <d...@jones.dk> > > X-Debbugs-Cc: debian-de...@lists.debian.org, build-common team > > <team+build-com...@tracker.debian.org> > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > * Package name : dh-rust > > Version : 0.0.1 > > Upstream Contact: build-common team <team+build-com...@tracker.debian.org> > > * URL : https://salsa.debian.org/build-common-team/dh-rust > > * License : GPL-3+ > > Programming Lang: Perl > > Description : debhelper buildsystem for Rust code > > > > dh-rust provides a debhelper buildsystem to build Rust code. > > . > > This builds and tests binaries and libraries from rust crates, > > the latter installed as source code below /usr/share/cargo/registry. > > . > > Feature highlights, compared to dh-cargo: > > * supports workspace (i.e. multi-crate project) > > * allows overriding CARGO_HOME > > * installs crate contents using "cargo package" > > * can use debian/Cargo.lock or Cargo.lock during build > > * uses crates below debian/vendorlibs when available > > * builds in make target dh_auto_build (not dh_auto_test) > > I'm still left a bit puzzled concerning who the target audience for dh-rust is > supposed to be.
Sorry for the description being unclear. I have tried hard to only state functional differences between this derivatives and its origin, the Rust team tooling. I have had difficulties even communicating with the Rust team (no doubt at least in part due to my own personality - I do not mean to throw blame). Suggestions for improving the description of the package is much welcome. > From the description I infer that I should probably switch the > following two packages to dh-rust? > > https://tracker.debian.org/media/packages/t/tuigreet/rules-0.8.0-4 > https://tracker.debian.org/media/packages/r/reform-setup-wizard/rules-1.0-7 > > Or am I misunderstanding the purpose of it? Generally, if your package do not need any of the features highlighted in the dh-rust package description, then you need not change tooling. You "should" never switch: Even if your package *do* need some features highlighted, you might consider collaborating with the Rust team to get those featured supported in their tooling, or find ways to work around limitations. Specifically for the packages you list, you might consider using dh-rust to reduce boilerplate: dh-rust seems (from a quick look, I haven't tested more detailed) to support those build needs without needing to bypass the dh-* helper and call the cargo wrapper, which involved declaring a pile of boilerplate variables. Or, as mentioned above, you might instead collaborate with the Rust team to improve their tooling to better cover your use-cases. The aim of dh-rust is to get rid of the cargo wrapper altogether. the team behind dh-rust find it suboptimal to have a perl library call a Python script that calls a Rust executable, and is working towards handling the functionality of that Python wrapper script within the perl library. That is work-in-progress, however, so not sensible to document yet - just mentioning to help get a feel for where the dh-rust project is headed in the hopefully very near future. Thanks for your interest in dh-rust, and inspiring approach to discussing it, - 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
