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 :-)
