Yay: Some way to prevent yay from aborting on a single build error?

[alxpettit]

Yay just canceled upgrading like 30 more packages that were unrelated. I assume this is the intended behavior (using yay v8.1173.0 - libalpm v11.0.1). I don't think this should be the default behavior.

[alxpettit]

I have to restart yay over and over again, memorizing a list of packages not for it to try to upgrade so I can upgrade the ones that are working... 2 14 13 12 17

It's like some kind of weird puzzle/memory game.

[Morganamilo]

This has been brought up enough that it's clear people want it.

As I've pointed out this can result in dependency errors. If bar depends on foo, and building foo fails, then going on to try and build bar will fail due to dependencies.

It's not that big of a problem seems as we never use --nodeps so it will just bail out, it will never cause an invalid state. Bit it's still a problem.

So either we just leave it to the user to say they want to skip and blindly move on or we do the smart thing and recalculate the deptree. I'm not really sure which one to go for.

[alxpettit]

@Morganamilo I'd prefer to recalculate the dependency tree iteratively on each error, canceling every package that has a failed dependency, but proceeding with the rest. It'll have to robustly iterate up the tree when there's a dependency chain with a length greater than one...

This (I think) simply means recalculating every time there's an error, so if we start by canceling a grandparent node, we can recalculate twice, in each iteration, to end up canceling the child and parent nodes. It doesn't really have to be computationally optimal because this code won't be iterating THAT many times, so simple full deptree recalculation on each iteration seems fine to me.

Is that complicated with the current code base? It sounds intuitively easy to me, but I haven't actually worked on the code.

[Morganamilo]

It sounds easy when you talk about it in terms of a simple tree. But in the real word were dependencies are more graph like with cycles and duplicates it gets a little more complicated.

For example if I'm installing java-program java7 and java8, if java7 fails to build then we would still build java-program because java8 is still there to satisfy it.

Off of my head the way to solve that would just to run isSatisfied() on every package, removing the ones with missing deps. Repeat until you get a loop with 0 packages removed. That might be slow though.

Another case is if the aforementioned foo fails to build. Well what if foo-git is available? Well it would make sense to use that instead. But now you have a new package, so we need to show the diffs and all that again.

All of these cases talk about installing packages. But I see this feature most useful when upgrading, where dependencies don't usually come into play (of course they can an sometimes do). This makes me lean towards the simpler less perfect solution.

[Jguer]

Off of my head the way to solve that would just to run isSatisfied() on every package, removing the ones with missing deps. Repeat until you get a loop with 0 packages removed. That might be slow though.

It might be slow but only applies in fall out cases so normal execution is not affected.

Another case is if the aforementioned foo fails to build. Well what if foo-git is available? Well it would make sense to use that instead. But now you have a new package, so we need to show the diffs and all that again.

I would just exit here, triggering a full installation cycle with our current architecture is going to create unforeseen issues

[Jguer]

Closing in favor of #848