Ensure aurWarnings will always be printed out in one block
use '->' for printing aur warnings and ignored upgrades
use '->' for conflict printing
use '->' for key importing
Say PGP keys not GPG keys
Add back green for input prompts
Use 4 spcaces over \t
Before `yay -Syu` called `pacman -Sy <pkgs to upgrade>`
We then later switched to it calling `pacman -Syu` this lead to yay
seeing no targets to when it was upgrading a bunch of packages it
assumed they must be deps. Correct this by adding repo packages to the
targets list.
Also ensure we dont mark packages as dependencies if they are already
installed. For example we install `foo` which requires `bar>5` but we
only have `bar=4` installed. In this case installing `foo` will pull bar
in as a dependency but it should not be marked as such because it
already exists.
Split by dots, pluses, dashes, tilds, etc., not only `Version` and `Pkgrel`.
Don't make new version different bold.
Inspired by [`pikaur`](https://github.com/actionless/pikaur).
This means that menus are now printed in noconfirm mode, I don't see
this as a problem because Pacman still prints its questions during
noconfirm.
When the user has edited pkgbuilds Yay will prompt if they want to
continue with the intall. This prompt is also enabled during noconfirm
to ensure the user is happy with the pkgbuilds.
Before versioned deps with the same name would be combined into a single
version range.
For example:
`foo>1 foo>3 foo<4 foo<5` would be merged into the range `3<foo<4`
This was assumed to be fine because of course no package is going to
have conflicting dependencies `foo>3 foo<1` but what was not thought
about it that a package or packages could provide multiple versions of
a provider. Java being example, you could have 8 and 9 provided for at
the same time.
This then causes a problem when you try to install two packages at once,
one requiring `java<8` and the other `java>9` when combined this leads
to a range that can not be satisfied.
Instead we now never merge dependencies but check them all individually.
We also make sure to pull in all already installed providers. The reason
for this is, before if a package did not apear in the dep tree we
assumed it to be satisfied because of the .FindSatisfier in the dep
resolving. So if you installed a package that needs `foo=1` and you
already had a package providing that it would not be in the dep tree and
we assume it is fine. But if you install a package that needs `foo=1`
and install a package that prvoides `foo=2` then foo will all of
a sudden be in the dep tree but only version 2 will be there. For this
reason we also load all the already installed packages in so that the
`foo=1` will be there.
