The cause is, that data structures are being used by the dependency solver which do not preserve the order, since they are only used for "is it inside?" and "is it not inside?".

Normally that's not a problem, but with this mingw-w64-* packages it is. As you can see, when the dependency solver tries to find a solution when using the mingw-w64-headers-bootstrap-5.0.3-1 dependency, there is no such solution. When not using it, there is a solution.

Unfortunate, but I guess I'll never change anything about it, because the real problem is the package. "Fixing" it is not even really possible, I could "fix" the consistency of aurman but that does not really help, since it is still quite impossible to detect which packages to use in order to find a solution.

This looks like a serious flaw in aurman.

To be honest: It is not. I do not feel like explaining why this is the case, because you have to look deep into the algorithm. Trust me with it or do not, I am nevertheless not going to change anything here

The equivalent of this behavior is if the AUR RPC would send the dependencies in a different order. You have to start "somewhere" when solving dependencies, and you can do that at the first item. The result is going to change then, if you are dealing with e. g. this mingw fuckery

Thanks! Will look into mingw packages then

Looks to me as yet another case of unnecessary complex implementation that results in naughty side effects - solving the mingw bootstrap issue that ends up breaking the solver, or whatever issue you tried to solve in the first place.

And what we obtain is an unreliable dependency solver, with the very same action resulting in different predicted packages. But sure, let's agree to disagree.

Nothing is broken. Absolutely nothing.

Nothing is broken. Absolutely nothing.

Look, I understand that constantly dealing with crappy users tends to put you on the defensive when dealing with criticism - I've been there before. However, it doesn't mean the dev is always right - and I've myself observed this many times before.

Having cases that can't be handled? That's fine, every helper has difficulty in a situation or another. But having cases that produce different results with the same input - while the AUR RPC data doesn't change - is a flaw. There is something to fix here, either by handling the case correctly or by stopping the process with an error message.

Regardless of the implemented algorithm, the solver is unreliable. From an user point of view, the question that naturally arises is "When can I trust aurman and when can I not?"
As of now, it is difficult to answer this question, and I certainly wouldn't claim that aurman has a reliable solver.

Something is certainly broken, yes.

However, it doesn't mean the dev is always right - and I've myself observed this many times before.

I've never said that the dev is always right. Anyway: I think that I am right in this case, let me explain in detail what is going on and why I have no intention to change anything.

In order to be able to build/install a package, all dependencies of that package need to be fulfilled. There is no such thing as "ordered" dependencies, a dependency is fulfilled or it is not. If there are all dependencies fulfilled, you may build/install, otherwise you may not.

The logical mathematical representation for dependencies is thus a set, which does not represent any kind of ordering. In fact, aurman uses sets at many points in the sourcecode when dealing with dependencies because of the O(1) lookup time, to check if a dependency is inside a set or not.

Now back to our problem. aurman -S nsis yields different results when executing multiple times. What happens is the following:

aurman fetches the needed dependencies and puts them into a set. At this point the ordering gets lost. You may iterate over a set, but the order for iterating is almost likely a different order than the order in which you put the dependencies into the set. When trying to solve the dependency problem, aurman iterates over the set, to fulfill the dependencies one by one, until all of them are fulfilled. With normal packages, that simply leads to a valid solution. NOTICE: The order in which the packages appear in the intern aurman solution may also be different here during different executions, but it really does not matter, as long as the packages are topologically sorted, the concrete order does not matter, as long as it is correct.

The mingw-w64-* packages however are different, you may not simply fulfill the dependencies, just look it up yourself, try to solve the problem with a pencil and paper and you'll see what happens. aurman supports the kind of bootstrapping, however the nsis package leads to even more fuckery than the normal mingw-w64-gcc package. It in fact matters, in which order the dependency solver of aurman tries to fulfill the dependencies, to find a valid solution. If the solver gets the mingw-w64-headers-bootstrap dependency before the mingw-w64-headers dependency, a solution cannot be found. Vice versa the solution can be found. This is quite impossible to detect programmatically, the only sensible thing to do would be to calculate the possible permutations of the dependencies (O(n!)) and try to solve the problem for all such permutations. This is clearly insane and nothing one should ever do.

Leaves us with: "But it is inconsistent", to which the answer is "Yes, but it does not matter unless your package is garbage". I could make it consistent by e.g. ordering all dependencies alphabetically when working with them, but that is complete nonsense. It leads to consistency but without any rational benefit. The correct mathematical representation is a set, changing this just for consistency without any other kind of benefit does not make any sense in my opinion, which is why I am not going to change anything here. By the way: The answer to the question

When can I trust aurman and when can I not?

Always, if aurman finds a solution, it is valid. The inconsistency in finding solutions does not mean, that there are invalid solutions which can be found by aurman mistakenly.

Always, if aurman finds a solution, it is valid.

With due respect, a solver that doesn't succeed when a solution exists, or that finds different solutions to the same input (sometime valid and sometimes not) is the opposite of "reliable" - by definition. I guess we have a very different definition of "reliable solver".

I understand what aurman tries to do, but it seems to aims at a tree in an over-engineered way but eventually miss the forest. When I see the simpler algo implemented in the deprecated pacaur actually achieves consistent and good results at the same issue, I can't do anything but roll my eyes.

But yes, solving dependencies is indeed a complex problem, and there is much progress to do among helpers here. I'm however not sure how you could claim aurman has a reliable solver - it's clearly not. Maybe because of your design that bring other advantages at the table, but it's inhenrently not reliable.

When I see the simpler algo implemented in the deprecated pacaur actually achieves consistent and good results at the same issue, I can't do anything but roll my eyes.

pacaur is able to install mingw-w64-gcc?

or that finds different solutions to the same input (sometime valid and sometimes not)

I explicitly stated that aurman does not find invalid solutions

Anyway: I made my point, unless you provide technical/mathematical arguments on how to solve this in an appropriate way, that's it. You saying: "I do not like it" without any constructive feedback on how to actually do it, does not help anyone. Saying: "It is wrong, fix it" is easy, but if you want to help me, provide useful feedback on how to do it. Everything else is useless

Anyway: I do not feel like I want to develop this project as of now with feedback via GitHub issues anymore.

There are some valid reports like this one, but I am seriously too tired of all the nonsense which I have to discuss. aurman is working for me, my semester break is almost over and I want to focus on my degree. There is likely one aurman rewrite as my bachelors thesis, but currently I feel like I need a break from the whole AUR "community". Going to deactivate the issues later today, guess I'll ask @AladW to remove aurman from the AUR helper page, too. Not interested in new users, current users may migrate to yay.

I explicitly stated that aurman does not find invalid solutions

Which isn't the problem...

Anyway, if you want to look at a reliable solver, check out libsolv from SUSE - they use a satisfiability
algorithm - I guess it's at least in part similar to what aurman does, but with better constraints. They provide python bindings too, and have support for Arch repo (but not AUR).

Anyway: I do not feel like I want to develop this project as of now with feedback via GitHub issues anymore.

Very well - that I can understand.

@polygamma on the constructive side of things, in case it was an honest question and an answer might be useful. If you want the algo to be deterministic, use a sorted set for example. It's a set, you cannot have duplicates there and checking for existence is O(ln(n)) (not O(1) BTW). But it is also an ordered set, so you can always take a "lesser" element from it. Successful resolving will be deterministic as well (order of built packages).

Another alternative is to have a linear queue and an additional set I guess. Use the set to check existence, otherwise add to the linear queue. You don't need to remove deps, so I guess that works too.

Most importantly, enjoy your contributions and have fun.:) Don't mean to pressure, just throw in some technical answers to questions mentioned.

// If you'd ask me, I'd say the implementation looks like a "reliable" solver, but not "deterministic". Without determinism users aren't happy though :shrugs:.