Re: Bug#1076153: ITP: dh-rust -- debhelper buildsystem for Rust code
On Thu, Jul 11, 2024 at 06:06:21PM GMT, Jonas Smedegaard wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Jonas Smedegaard <dr@jones.dk>
> X-Debbugs-Cc: debian-devel@lists.debian.org, build-common team <team+build-common@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-common@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-----
>
Reply to: