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.