• Bug#1094199: dh-rust: installs lib crates in non-deterministic and fall

    From NoisyCoil@21:1/5 to All on Wed Feb 5 22:20:01 2025
    Package: dh-rust
    Version: 0.0.10
    Followup-For: Bug #1094199
    X-Debbugs-Cc: noisycoil@tutanota.com, jonas@jones.dk

    Hi Jonas,

    Has there been any progress on this bug? It is currently blocking the bindgen transition (via oxigraph) and may possibly block other updates to come (some evidence of this in Bug #1095177).

    Is there some way I can help? Unfortunately my knowledge of perl is basic if any, but if you have something in mind feel free to ask.

    Cheers!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonas Smedegaard@21:1/5 to All on Fri Feb 7 23:20:01 2025
    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