Quoting NoisyCoil (2025-02-07 18:30:17)
Package: dh-rust
Version: 0.0.10
Followup-For: Bug #1094199
X-Debbugs-Cc: noisycoil@tutanota.com, jonas@jones.dk, bengen@debian.org
Hi Jonas,
Just putting some ideas out there, not sure they will actually help but at least I tried.
Why should dependencies be installed in the correct order in the first place, in practice? Why can't they just be installed in a random order, and whatever crate needs to be actually compiled (or checked) is compiled/checked after that?
I suspect this bug is caused by the same underlying issue of Bug #1094483, namely dh-rust relying on `cargo package` to install the library crates. As I noted there, `cargo package` inspects the dependencies in the registry before doing the packaging, so it needs them to be already installed in the registry.
In relation to Bug #1094483 this approach fails because it requires all check-dependencies to be installed even when no checks are to be performed, which is logically useless (I believe). Here it fails because it requires all dependencies of a package to install to be installed, which not only is probably useless as well, but may cause the dependency cycles Hilko observed.
I also suspect these cycles cannot be broken easily in some circumstances, like those that require packaging single-feature crates (those that force one to use collapse_features = false, to make myself clear). Thus correct dependency
order resolution should probably happen at the feature level, not at the crate
level, if it is to work always without manual intervention. This is of course assuming that one has fixed the cycles caused by dev-dependencies, which Hilko
observed as well IIUC.
If the install stage is kept separate from the build/check stage then I don't see issues with installing crates in a random order. If there are issues, then
it may be that `cargo package` is introducing them artificially just because it
needs to do its preliminary checks. If those checks are not needed in debian packaging then it's probably best to find another solution (either not using `cargo package`, or patching it in such a way that those checks can be avoided
optionally, and then upstream the patch).
Of course it may be that I'm totally missing something, like the reason why dependencies should be installed in a fixed order, from a logical perspective (i.e. regardless of `cargo package`). If this is in fact the case I apologize for wasting your time :-)
It seems to me that you are not talking about or investigating a bug in dh-rust, but instead explorating constraints of cargo itself.
If you think that cargo can more flexibly do "cargo install" without
requiring certain order, then great - but I do think that it is more
sensible to fork that issue and tie it to cargo, as I fail to see how
dh-cargo can magically make the constraints of cargo go away.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website:
http://dr.jones.dk/
* Sponsorship:
https://ko-fi.com/drjones
[x] quote me freely [ ] ask before reusing [ ] keep private --==============965793691554093714=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"
-----BEGIN PGP SIGNATURE-----
wsG7BAABCgBvBYJnpoSLCRAsfDFGwaABIUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmfudqnFpMHaCsKtSGo000TBdIvXQBwKieW25Sbe1sfs 0hYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAAAROA//Vi+ASpIibwlKn+QZxzbTrXz8 DXaUSGLLzAQNo3NfRMp+UfoRJ+UyAFPMEpy6QpbszVhithbiNCOH+t1RqwSc1/Mn HdZWk4tutBUxWKtkhdd23jpbVVvRbFJno056isIAuRMWVkmxbrZad9WB+OVbU0Mf dFume3dx8QH/OogaBGQZgPvWYBS3vSPJbS7yEyWOqxdArJMsX9Pd+f4McuGpYORd KC9nCUpkxAz1sVIUY5OvaSripxtQUOAjhbQUirMrcrDmq2MxGyJKSxAtMbkSGybc X34W/kG5+Xwu/GbFuNWWsFZqypIj32BbC+px94SpHa667lKrM6tlff8YhDVSZX7t UlbNMXyiWV2eSDajxZnh9O13dUBq3igUEY3TpRSK