Yay first calls 'makepkg --nobuild -fC' to update the pkver. Later on we
call 'makepkg -cf --noectract --noprepare --holdver' to actually build
the package.
Inbetween these two calls we keep the already extracted
sources to save time on the reextract and duplicated call to prepare
(pkgbuilds should not require user input but things such as linux-ck do
and calling prepare twice will actually cause them to promt twice)
We also have two checks. First we see if the package is already
installed and up to date (--needed) and secondly we check if the
package is already built.
If any of these conditions are met we skip building the package. This
leaves a dangling src/ directory as 'makepkg -c' was never ran.
Now if these conditions are met tell makepkg to cleanup and exit.
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 go root might be in different places if the user is using
a different go binary that is not managed by the system (eg
/usr/local/bin/go). In this case the go binary should be smart enough to
default to it's own go root. Or if there are still problems, it is on
the user to configure it themselves.
