Re: can't run 0compile on windows .

On Fri, 30 Nov 2018 at 21:25, Bastian Eicher <[email protected]> wrote:
>
> Hi guys,
>
> the C# solver always tries to find a 64-bit solution first when running on a
> 64-bit system and only considers 32-bit solutions if that fails.
> http://repo.roscidus.com/python/python-gobject only has an i486 build for
> Windows. Therefore it cannot be part of a valid 64-bit selection.
> http://0install.net/2007/interfaces/ZeroInstall.xml still lists some
> versions without a dependency on python-gobject, e.g. 1.14.
> Therefore the solver will prefer to use this old version of Zero Install
> rather than falling back to i486 for the entire selection and thus end up
> still providing a solution leading to "No module named gobject".

OK, I've updated the published 0compile feed to give the direct dependency.

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.

For reference, the order used by the OCaml version is here:

https://github.com/0install/0install/blob/dca085e7211332fa19016a69240e331e79dcde00/ocaml/zeroinstall/impl_provider.ml#L169

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.

> Since the C# solver uses simple backtracking rather than a SAT solver, it
> takes quite some time to find this solution.

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?

> The following works on Windows and only takes a few moments:
> > 0install run --cpu=i486 http://0install.net/2006/interfaces/0compile.xml
>
> @Thomas: If you could add the python-gobject dependency to the remaining
> implementations in the ZeroInstall feed I believe it would prevent this
> issue.
> However, the solver would probably still take a long time until it realizes
> it has to down 32-bit lane.
> In order to speed up the process I suppose we should also add the
> python-gobject dependency directly to the 0compile feed.

Done.

> Further down the road, I have some optimizations for the C# solver planned,
> as time permits.


-- 
talex5 (GitHub/Twitter)        http://roscidus.com/blog/
GPG: 5DD5 8D70 899C 454A 966D  6A51 7513 3C8F 94F6 E0CC