If the package is already installed, we need to check if it is in the
repos to see if it aplies to rebuild tree. Normally alpm will not prompt
us to select a provider if we already have one installed. An exception
comes up when we have a provider installed that is from the AUR. In this
case FindSatisfier() still asks us to select a provider.
Now make sure to never to never show the menu if the package exists in
the local repo.
Previous default SigLevels caused 3rd party databases to take a very long time to
load and also to not load properly. Probably due to missing keys(?).
Pacman takes a long time to check the databases. For now, always set to
SigLevel 0 like how go-alpm did in its config parsing. Needs more
looking into for a proper fix.
This moves the config parsing from out of alpm and into the
go-pacmanconf libary plus some boilerplate code to get it into our alpm
config.
This makes sense as many config options such as UseColor and CleanMethod
have nothing to do with alpm and only relate to pacman.
pacman-conf is used instead of direct config parsing. This tool resolves
defaults and includes for us, so we don't need to handle it.
It is now safe to drop all the config parsing from go-alpm.
The main reason behind this is for future localisation. yes and no can
be set to the localized equivalent and it should just work.
This Refactor also changes the function in ways which make it much less
confusing.
The param is no longer reversed and changed to a boolean. Before you had
to pass in Yy to get a default of no and vice versa.
The function now retuens false for no and true for yes. Before it would
return true if the default option was choosen.
Currently When performing a system upgrade, Yay will first refresh the
database then perform the repo and AUR upgrade. This allows Yay to add
some features such as better batch interaction, showing potential
dependency problems before the upgrade starts and combined menus
showing AUR and repo upgrades together.
There has been discussion that this approach is a bad idea. The main issue
people have is that the separation of the database refresh and the upgrade
could lead to a partial upgrade if Yay fails between the two stages.
Personally I do not like this argument, there are valid reasons to Yay
to fail between these points. For example there may be dependency or
conflict issues during the AUR upgrade. Yay can detect these before any
installing actually starts and exit, just like how pacman will when
there are dependency problems.
If Yay does fail between these points, for the previously mentioned
reasons or even a crash then a simple refresh will not cause a
partial upgrade by itself. It is then the user's responsibility
to either resolve these issues or instead perform an upgrade using
pacman directly.
My opinions aside, The discussions on the Arch wiki has reached
a decision, this method is not recommended. So to follow the decided
best practises this behaviour has been disabled by default.
This behaviour can be toggled using the --[no]combinedupgrade flag
It should be noted that Yay's upgrade menu will not show repo packages
unless --combinedupgrade is used.
--ask is no longer used when installing AUR packages, instead pass no
confirm when we know there are no conflicts and wait for manual
confirmation when there are.
This means that when there are no conflicts there should be no change in
behaviour and the user will not need to intervene at all.
The old behaviour can still be used with --useask.
Following the improvements in #480, #485, #486, a tiny bit of cleanup for a lone, forgotten line.
Plus the typo had been bugging me since I first saw it.
Clean build needs to happen before downloading pkgbuilds so that they
can be deletd before downloading.
Editing and diff viewing needs to happen after downloading the
pkgbuilds.
Prevously we asked to clean and edit at the same time. Then clean,
download pkgbuilds and open the editor.
This poeses a problem for diff viewing and editing. It's likley that the
user will see the diff and use that to decide if they want to edit the
pkgbuild. Using the current method, the user will be asked to view diffs
and edit before actually seeing any diffs.
Instead split cleaning diff showing and editing to three seperate menus
in the following order:
show clean menu
clean
download pkgbuilds
show diff menu
show diffs
show edit menu
edit pkgbuilds
Also each menu is seperatly enableable. By default only the diff menu is
shows. If the user wishes to clean build, edit pkgbuilds or disable
diffs then the user can use the --[no]{clean,diff,edit}menu flags. This
replaces the --[no]showdiffs flags.
diff viewing can be toggled via --[no]showdiffs. When enabled diffs will
be shown for packages between the current HEAD and upstream's HEAD.
Packages downloaded via tarballs will be shown in full using the editor
git diff is used to show diffs. Therefore the pager for diffs can be
set via the PAGER and GIT_PAGER enviroment variables.
These flags limit operations to only check the repos or only check the
AUR. These flags apply to -S, -Si and -Su.
-a may also be used as a short option for --aur. --repo has no short
option as -r is taken.
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.
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.
