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>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
* Package name : dh-rust
I would be happy if this makes it to the archive, though. Would be easier to >have a dh for rust which would be specifically useful to build packages that are
not just crates, but instead use multiple language including but not limited to
rust.
As an addendum, also gives freedom to maintain packages outside of the giant git
repo of crates, without having to embed this code in every such outside-of-team
maintained package.
On 11.07.24 18:06, Jonas Smedegaard wrote:
* Package name : dh-rust
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
This ("build-common") reminded me of cdbs. Can we not have another
schism and actually work together?
cdbs also got orphaned but its legacy not cleaned up. I still count
1.6k reverse build-depends in unstable.
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.
* Package name : dh-rust
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
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.
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?
Hi Birger,I didn't know that you were making patches easy to be cherry-picked.
Quoting Birger Schacht (2024-07-12 08:17:12)
On 7/11/24 9:55 PM, Jonas Smedegaard wrote:I have tried but failed to work closely with the Rust team. It was a
Quoting Philipp Kern (2024-07-11 21:13:42)This still does not answer the question why a fork is the better option
I'd - at the very least - would like to see a statement why a fork isdh-cargo is designed to repackage prepackaged code projects already
necessary. Innovation can happen in forks. But they don't necessarily
need to be in the archive to make a point.
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.
instead of working with the people behind dh-cargo to integrate those
features into the codebase?
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:
Le 12/07/2024 à 10:35, Jonas Smedegaard a écrit :
Quoting Birger Schacht (2024-07-12 08:17:12)I didn't know that you were making patches easy to be cherry-picked.
On 7/11/24 9:55 PM, Jonas Smedegaard wrote:I have tried but failed to work closely with the Rust team. It was a
Quoting Philipp Kern (2024-07-11 21:13:42)This still does not answer the question why a fork is the better
I'd - at the very least - would like to see a statement why a forkdh-cargo is designed to repackage prepackaged code projects already
is necessary. Innovation can happen in forks. But they don't
necessarily need to be in the archive to make a point.
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.
option instead of working with the people behind dh-cargo to
integrate those features into the codebase?
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.
I would have tried otherwise
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:
I would be happy to take all your patches that makes sense.
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 339 |
Nodes: | 16 (2 / 14) |
Uptime: | 00:04:07 |
Calls: | 7,466 |
Calls today: | 2 |
Files: | 12,691 |
Messages: | 5,627,862 |