On Fri, Nov 03, 2023 at 03:24:07PM +0100, Eduard Bloch wrote: > Hallo, > * Fabian Grünbichler [Fri, Nov 03 2023, 01:57:08PM]: > > > Eduard Bloch <e...@gmx.de> hat am 03.11.2023 13:46 CET geschrieben: > > > > > > > > > Hallo, > > > * Fabian Grünbichler [Fri, Nov 03 2023, 12:32:50PM]: > > > > > > > > the version of Cargo seriously needs an update. Because the word is > > > > > moving and the old version performs increasingly bad. > > > > > > > > the upgrade (to 0.70.1, since later versions require a lot of NEW > > > > processing first) is being prepared, but it takes a long time because > > > > it is very involved. > > > > > > > > https://salsa.debian.org/rust-team/debcargo-conf/-/issues/48 > > > > https://salsa.debian.org/rust-team/cargo/-/merge_requests/21 > > > > > > > > also related, and hopefully improving this in the future: > > > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054658 > > > > https://salsa.debian.org/rust-team/rust/-/merge_requests/27 > > > > > > Okay, I get the idea. That said, I find it quite strange that you want > > > to include a Python dependency in order to run a central Rust tool. > > > > > > Would you like me to rewrite the proposed cargo wrapper script into a > > > native Rust app? That's a serious offer, I have IMHO sufficient Python > > > and Rust experience, recently working on something partly similar > > > (https://gitlab.com/setecastronomy/wec ). > > > > > > I am not sure what you are referring to, but the fact that some > > helper/wrapper scripts are written in python is in no way related to what > > is making updates cumbersome at the moment. > > I was refering to the last link from the post above: > > https://salsa.debian.org/rust-team/rust/-/merge_requests/27/diffs#98066737513db2808acb090ffe631b89bd788499
that is not related at all either to updating cargo, or merging the two source packages.. > > and we most definitely don't want to rewrite the cargo wrapper in rust, > > that would serve no purpose at all. > > Depends on the whole picture. From that statement I understand that > reducing dependencies on further interpreters (like Python) is not a > goal here. it is indeed not, see below. > > > (Not sure about bootstrapping, though. Is rustc available while our > > > source package is being built?) > > > > of course rustc is required to build both rustc and cargo, since both are > > written in rust. note that rustc itself also has a build-dependency on > > python anyway, since it's (internal) bootstrapping/build tool is written in > > python (and rust). > > Okay. But I did not have only build-deps of the Debian source package > in mind, more the dependencies of the binary package, i.e. what the > regular user (application developer) gets. Why should cargo have a > dependency on Python? Looks quite strange to me. it should not - but it also does not. cargo (the package in Debian) only suggest python3. you can use (/usr/bin/)cargo (the binary as packaged in Debian) without having python installed. only when you use cargo via the wrapper script /usr/share/cargo/bin/cargo, which exists for integrating cargo into Debian packaging, would you need to have python3 installed. that script is not in anyone's $PATH (by default), and is only supposed to be called directly or indirectly via d/rules (manually after doing the appropriate setup steps, or via dh-cargo) when building a package. dh-cargo as a result depends on python3, but that is not relevant for someone just installing cargo to run cargo-the-binary for application development.
signature.asc
Description: PGP signature