Quoting NoisyCoil (2025-02-07 18:30:17) > Package: dh-rust > Version: 0.0.10 > Followup-For: Bug #1094199 > X-Debbugs-Cc: noisyc...@tutanota.com, jo...@jones.dk, ben...@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
signature.asc
Description: signature