Fail to install mingw-w64-gcc

[ismaelgv]

I've succesfully installed mingw-w64-gcc with trizen and other managers, but aurman fails to solve dependency tree:

~~ analyzing installed packages...
~~ fetching upstream repo packages...
~~ fetching needed aur packages...
~~ calculating solutions...

!! While searching for solutions the following errors occurred:
:: Conflicts between: mingw-w64-gcc-7.3.0-1, mingw-w64-gcc-base-4.9.2-1
Way to conflict: mingw-w64-gcc-7.3.0-1 -> mingw-w64-crt-5.0.3-1 -> mingw-w64-gcc-base-4.9.2-1
:: Dep cycle: mingw-w64-gcc-7.3.0-1 -> mingw-w64-crt-5.0.3-1 -> mingw-w64-gcc-7.3.0-1

2018-02-27 14:34:20,393 - classes - validate_and_choose_solution - ERROR - No valid solutions found
!! we could not find a solution.
!! if you think that there should be one, rerun aurman with the --deep_search flag

I have also tried to install it with --deep_search:

~~ analyzing installed packages...
~~ fetching upstream repo packages...
~~ fetching needed aur packages...
~~ calculating solutions...

!! While searching for solutions the following errors occurred:
:: Dep cycle: mingw-w64-gcc-7.3.0-1 -> zlib-1:1.2.11-2 -> glibc-2.26-11 -> linux-api-headers-4.14.8-1 -> tzdata-2018c-1 -> filesystem-2017.10-2 -> iana-etc-20180221-1 -> libmpc-1.1.0-1 -> mpfr-4.0.1-1 -> gmp-6.1.2-1 -> gcc-libs-7.3.0-1 -> bash-4.4.019-1 -> readline-7.0.003-1 -> ncurses-6.1-3 -> mingw-w64-crt-5.0.3-1 -> mingw-w64-gcc-7.3.0-1
:: Conflicts between: mingw-w64-gcc-7.3.0-1, mingw-w64-gcc-base-4.9.2-1
Way to conflict: mingw-w64-gcc-7.3.0-1 -> zlib-1:1.2.11-2 -> glibc-2.26-11 -> linux-api-headers-4.14.8-1 -> tzdata-2018c-1 -> filesystem-2017.10-2 -> iana-etc-20180221-1 -> libmpc-1.1.0-1 -> mpfr-4.0.1-1 -> gmp-6.1.2-1 -> gcc-libs-7.3.0-1 -> bash-4.4.019-1 -> readline-7.0.003-1 -> ncurses-6.1-3 -> mingw-w64-crt-5.0.3-1 -> mingw-w64-gcc-base-4.9.2-1

[AladW]

Dependency cycles can't be solved, any solution can only be guessed. aurman is correct in this case to abort.

[polygamma]

aurman is working as intended there. mingw-w64-gcc deps on mingw-w64-crt which deps on mingw-w64-gcc-base

But mingw-w64-gcc-base lists mingw-w64-gcc as conflicting.
So the listed conflict ist correct.
Hence aurman tried to find another provider for mingw-w64-gcc-base which is mingw-w64-gcc , but that is a dep cycle.

[ismaelgv]

Ok! Sorry for the noise then.

[polygamma]

I have implemented a new dep solving algorithm. See b11d68b

It should work now. I am not trying to solve the dep cycle, aurman just allows packages which have been only needed for building (make and check depends) to be removed again. So mingw-w64-gcc-base is being installed for building mingw-w64-crt and finally being removed when mingw-w64-gcc gets installed. Let me know if it works for you!

[rmarquis]

This sounds like a hacky way to get this specific package installed, but what if you have a real dependency cycle?

[polygamma]

Then that is being shown and aborted. As I said: I am not handling the dep cycle, I am handling the order of installing the packages to solve the conflict.

[ismaelgv]

It actually works. aurman asks the user when there is a conflict and a package must be removed. I don't know if this solution has any other side effects.

[polygamma]

Let me explain in more detail what I have done and why it should not have any downsides besides possible implementation bugs.

At first regarding the "dep-cycle" from the beginning of this issue. There is not really a dep-cycle, aurman just found a possible dep-cycle while trying to resolve the conflict.

Again: mingw-w64-gcc deps on mingw-w64-crt which deps on mingw-w64-gcc-base
Naive approach: Install base, crt and finally gcc. That does not work, since base conflicts gcc. Hence aurman tried to find an alternative provider for the base. See https://aur.archlinux.org/packages/mingw-w64-crt/

mingw-w64-gcc is an alternative provider, so aurman tried that, but that leads to the mentioned dep-cycle. At that point the old dep solver just presented this problems and aborted, as listed in this issue.
That's perfectly fine, but I wanted to resolve that, since as human I knew what to do, hence aurman should be able to solve that problem, too. So: The problem is not the dep-cycle, which is nevertheless unsolvable, but the conflict between gcc and base. You may notice: base is just a make dep for crt, so if we are able to build crt, we can forget about base and just remove it. That resolves the conflict between gcc and base.

To the changes of the dep solving algorithm:
I have fully implemented hypothetical appending packages to a "system" e.g. your real system with all the already installed packages. After appending the algo is able to find out, if only "not relevant" packages have been removed due to conflicts e.g. the base package after crt has been built. So aurman still finds this conflict, but is able to decide whether this conflict is really unsolvable, or irrelevant and can be ignored.

[rmarquis]

There is not really a dep-cycle, aurman just found a possible dep-cycle while trying to resolve the conflict.

Yeah, that's what confused me. This was a provider bug in the "holy solver", not an actual dependency cycle.
I do believe the solver tries a too complicate approach by default, since provided dependencies in the partially solved dep chain should actually not be an issue at all.

[polygamma]

Well, I am not a fan of "should" ;) The last commits change the behavior of when to check which things, I think how it is working now is relatively sane.

Some benchmarks of the solution finding:

[polygamma]

I count this as resolved for now.

[polygamma]

Since this issue led to completely changing the dep solving algorithm, I am posting new benchmarks here.

I have further improved the reaction of the algorithm to found problems while dep solving, hence
plasma-git-meta --deep_search is being calculated in under 2 seconds on my PC.

-S plasma-git-meta ros-lunar-desktop ros-indigo-desktop-full in just under a second and simple things like -S mingw-w64-gcc still in less than 0.1 seconds

Besides improving the handling of errors, I changed the algorithm for hypothetical appending of packages, hence aurman is now able to install solutions in chunks, e.g. the needed repo deps for an aur package just before building the package

[polygamma]

New feature: Show what the solution does, very interesting in some cases.

Two examples:

Don't mind the versioning, I did not run with --devel to not spam the output with git pulls

edit: behind --solution_way in master

[xantares]

this together with automatic pgp keys fetching is way too awesome, please insert some bugs here :)