[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cross compilation: dev packages depending on rustc



Am 13.02.24 um 23:22 schrieb James McCoy:
On Tue, Feb 13, 2024 at 09:54:34PM +0100, Johannes Schauer Marin Rodrigues wrote:
Hi,

Quoting James McCoy (2024-02-13 20:19:13)
On Tue, Feb 13, 2024 at 07:42:41PM +0100, Johannes Schauer Marin Rodrigues wrote:
I was wondering what this dependency on rustc is for and why it is
necessary.  If packages shipping C header files would depend on gcc, the
same thing would happen.

Can you shed some light on the situation?
This is because the crate states that its minimum rust version is 1.70.

https://sources.debian.org/src/rust-gdk4/0.7.3-1/Cargo.toml/#L14

Rust is in sort of a weird spot here.  The library crates exist solely
to build actual binary crates.  The package being built may not have a
minimum required Rust version, but the library crates that it
(transitively) Build-Depends on do, and that's what this is trying to
express.
instead of using a Depends, could a Breaks be used like this:

Breaks: rustc (<< 1.70), rustc (>> 1.70)
I was mistaken earlier.  We only automatically generate the rustc
version constraint for Build-Depends and autopkgtests.  These are
manually being declared, but presumably for a similar reason.

https://sources.debian.org/src/rust-gdk4/0.7.3-1/debian/debcargo.toml/#L5

I'll let Mattias comment on that.

This would not draw in a rustc dependency but would make it impossible to
install it together with the wrong rustc version.

I added this manually since the rustc at the time was below 1.70 . I needed to do this to ensure the newer rustc(from exp at the time) got pulled in during the transition. I guess it could be dropped now if it causes issues for cross-compilation.

best,

--
Matthias Geiger <werdahias>
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg

Attachment: OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature


Reply to: