Re: can't run 0compile on windows .
"Bastian Eicher" <[email protected]> Sat, 1 Dec 2018 23:39:20 +0100
| Newsgroups | gmane.comp.file-systems.zero-install.devel |
|---|---|
| Message-ID | <[email protected]> |
> OK, I've updated the published 0compile feed to give the direct dependency. Thanks. Seems to be working fine now. > However, I think it's a bad idea in general to prefer older versions just > because their dependencies are easier to install. > Newer versions tend to have more dependencies than older versions, so this > could easily lead to getting stuck on old versions of software if they add > a 32-bit-only dependency at some point. I agree. I'll try to get this behavior changed in the C# version soon. > For reference, the order used by the OCaml version is here: > [...] > score_machine (which prefers 64-bit binaries) is one of the last things it > considers. > > Once the solver has the 0compile implementations ordered by preference, it > will work down the list. e.g. if it decides that 0compile 1.4 is better than > 1.3 (which it will by default), then it will only install 1.3 if there is no > way to get 1.4. I actually modeled this part of the C# solver very closely upon the existing Python/OCaml code. Here you can see that the ordering logic is basically the same: https://github.com/0install/0install-dotnet/blob/master/src/Services/Solvers /SelectionCandidateComparer.cs However, rather than treating AMD64 as a superset of x86 and then forbidding the mixing of AMD64 and x86 in a single selection, the C# implementation simply treats AMD64 and x86 as incompatible and solves for them separately. This is what I'll probably need to change. > Is there some complexity threshold where it decides the cost of spawning a > subprocess is worth it to get the faster solver, and switches over? Yes. Once the backtracking solver has tried a certain number of implementation candidates for a single interface it gives up. This number is currently 32 (chosen somewhat arbitrarily). There is an additional "cost" to switching over to the OCaml solver, since it currently does not support HTTPS on Windows. So if it attempts to use any HTTPS-served feed that the C# solver did not already cache, it will fail.