On Thu, Jul 11, 2024 at 06:06:21PM GMT, Jonas Smedegaard wrote: > 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>
Hi! (all of what follows is my personal opinion and not coordinated with other members of the Rust packaging team). I know the team and you have had differences in the past about how to approach packing crates and/or software written in Rust, and I can and do respect the technical aspects of that (at least in parts). Some sort of attempt to reconcile your pre-existing vendored forks of the rust-team tooling with the original source, or at least a heads-up about this plan of yours would have been appreciated. I don't see any technical obstacles for having a single set of low-level Rust-helper tools for packaging. I see a lot of downsides to having two such sets that are 90% compatible, but subtly different and drifting apart over time. Please (seriously!) reconsider this, and try to work together with the existing Rust team to develop a/the common set of (low-level) tooling and helpers. A lot of the team members are also packaging Rust-related/using software outside of debcargo-conf (e.g., as part of the Gnome team), and desire similar features that you do for your workspace-based, packaged from git crates. > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > * Package name : dh-rust The name is pretty misleading IMHO, this is dh-cargo and a helper from the cargo package, forked and renamed (and extended), even though it is not Rust or rustc, but cargo that is the target here.. You also conveniently fail to mention that this is a (personal) fork of existing packages/scripts from existing packages. > 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+ This part in particular almost seems like a hostile takeover - the original tools are all MIT or Apache-2.0 licensed (the latter is not mentioned in your git history, but the cargo wrapper is copied from src:cargo or src:rust, which lists it as dual-licensed), and while you kept the copyright notices, you didn't keep the license text (which makes this a violation of the original license that require keeping it, at least covering those parts originally written under that license - unless you've actually gotten permission from all of the original authors and just didn't mention that anywhere..). With your "relicensing" you effectively made your forks live on the end of a one-way street - you can take changes made in the original tools authored by the Rust team, but prevent us from incorporating changes you (or other contributors) do on your end, unless they are explicitly dual-licensed, or our tools need to relicensed as well. While this is obviously okay for you to do from a license stand point (provided you keep the original license texts as well? but IANAL, etc.pp.), it's a bit like a slap in the face to your fellow Debian members in the Rust team, especially given the lack of communication. > 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) This is also factually wrong - dh-cargo doesn't build in dh_auto_test, it tests there. It builds in dh_auto_install, and I am currently working on changing that as part of integrating cdylib support.. But note that there is a reason it's done that way currently - cargo handles configs (including the override for using packaged crates) differently in `install` vs `build` - the latter can pick up a wrong config shipped by the crate/project itself, with higher precedence than the one managed by the wrapper, with all sorts of "fun" side-effects. > -----BEGIN PGP SIGNATURE----- > > iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmaQAvoACgkQLHwxRsGg > ASEvTQ//W+YQjP71QIGyP3bgs2Sow8pSRga9BkbY7vjGNGGih9FPGFxDmG18dSV0 > JcLHuksh+kjHxoDoFpufOLcNTBPf3AQG6O6VuySxt7cG9L27w1a7jxKBXvKtDAtW > 7ZBEi/fySLj5PyHYyZWY2fLmhEzBMmuNcY/l1wBklktF5Jkc7mwYSaqI/3mMxeeE > pa6btQuW3Mdf3SyZEc05eriNIi9A6wBTy0Yc+m7oU2QGo+2ckXy3hOcN2SjQR5OM > /h3NydY+bXP8V9Sz/wJ0qhep89Mh/CvEcKeNyw1BbKCHr1e+4UQ8WzEsWSq9c1+c > f8woy3KNbtt1JXpCaJcM2I+PBOIaZ0HupV4IzQYevbpSawgnLY5AsGruJgAHiERj > GVdBrykEj2YHfhw6clqJVTxx2sVYifLgOu5RiM4dGsBwMf0DpuqWXh3HeXnS6Z81 > 2xj0PTA5t38bQsqLW0JU1IOvzR4m/40SDMpTWo3FjWpc263QmjFMRXSVaUha8qQs > fV9WhL0jTjvNbrUxRM7jKaPyioGXk+RjXQtCJwAG5moJxDVVQD65oQy6Z0q+yZqF > xq9HLaqrC6At2rTyUxCVK5IDavMYXAL+IB7rkJ6ahG7ThDh8cPuSC5+0Ss2f65tB > QtAqmxKPvjr0uLUeMQAvMLWagKKVP39gmtLL7o5LH8OFhZ2DDIM= > =oOzs > -----END PGP SIGNATURE----- >
