When pkgbuilds are built by makepkg, if the pkgbuild's arch=() array
does not include the current carch set in makepkg.conf, makepkg will
fail to build the package.
Now, Yay detects if a pkgbuild does not support the arch set in
pacman.conf Yay will ask the user about this and ask them if they want
to build anyway, passing `--ignorearch` to makepkg.`
Note that Yay will check against the arch set in pacman.conf which is
what pacman uses to only allow installs of package of that arch. makepkg
will still use carch set in makepkg.conf to build packages. These two
values are expected to be the same otherwise Yay will fail.
The on disk .srcinfo is needed for this as the user should be asked pre
source download. This and pgp checking both use the on disk .srcinfo so
it is no longer a one off. Store the 'stale' srcinfos so they can be
accesed by both functions.
Fix typo where adding to has instead of depStrings
Error correcly when missing packages
Also handle cases where a package is provided multiple times. If one
package provies `foo=1` and another provides `foo=2` before the latter
would just overide the former version. Now both versions will be checked
against.
With the addition of pgp key checking in Yay, the srcinfo parsing was
moved to before the pkgver() bump, leading to outdated pkgbuild
information.
Srcinfo parsing must be done after the pkgver() bump
The pkgver() bump must be done after downloading sources
makepkg's PGP checking is done as the sources download
yays PGP importing requires the srcingo to be parsed
Quite the chicken and egg problem
It is possible to skip the integ checks after the sources download
then parse the srcinfo
do the yay PGP check
then run the integ checks
the problem here is that to generate the srcinfo `makepkg --printsrcingo` is ran
This causes the pkgbuild to be sourced which I am not comftable with
doing without the integ checks.
Instead we parse the on disk .SRRCINFO that downloads with the PKGBUILD
just for the PGP checking. Later on we parse a fresh srcinfo straight
from `makepkg --printsrcingo`. This is a little bit less efficient but
more secure than the other option.
The callback is set to allways silently say yes, When passing to pacman
for the intall pacman will then ask the question giving the user
a chance to answer.
Similar to the --redownload flag, when specifed targets will be rebuilt
even if an up to date version is cached. --rebuildall can be used to
ensure uninstalled dependencies are rebuilt as well.
Additionally, unlike --redownload there is also --rebuildtree. This
causes a rebuild and reinstall of a package and all of it's dependencies
recursivley. This is designed for when a libary updae, breaks an
installed AUR package due to a partial upgrade. polybar is a common
example
--rebuild allows you to easily skip the cache and rebuild against a newer
libary version. --rebuildtree is a more nuclear option where you can
rebuild the whole dependency tree.
Using a WaitGroup forced the code to wait for every goroutine to finish.
Using channels allows us to exit early if any of a packages sources need
an update. No point in waiting for the other requests to finish if we
know there is an update.
The update process was already partly parallel: repo, aur and devel
updates where each given their own goroutine.
This gives two further layers of parallelization. Firstly the
`needsUpdate()` function is now run in parallel for each package checked.
One package may have many vcs sources so `needsUpdate()` also checks all
of its sources in parallel.
This gives an aproxamte 3x speedup for `yay -Su --devel` timing from
when the command starts to when the number menu apears.
unfortunately git://bitbucket.org/volumesoffun/polyvox.git never
resolves on my machine for some reason so it always hits the 5 second
timout period.
It then moves on to http:/bitbucket.org/volumesoffun/polyvox.git/ which
does resolve as expected. I have not looked into it but I fear this
applies to all gitbucket repos. Luckly they are few and far between.
When building a package from the AUR for which there are missing keys,
yay will now prompt the user whether it should try to import such keys
using gpg:
[...]
:: Parsing SRCINFO (1/3): libc++ (libc++abi libc++)
:: Parsing SRCINFO (2/3): aurutils
:: Parsing SRCINFO (3/3): cower
==> GPG keys need importing:
487EACC08557AD082088DABA1EB2638FF56C0C53, required by: cower
11E521D646982372EB577A1F8F0871F202119294, required by: libc++ (libc++abi libc++)
B6C8F98282B944E3B0D5C2530FC3042E345AD05D, required by: libc++ (libc++abi libc++)
DBE7D3DD8C81D58D0A13D0E76BC26A17B9B7018A, required by: aurutils
==> Import? [Y/n]
[...]
Default is to try to import the problematic keys ([Y/n]).
when doing `yay -S foo bar` where `bar` is a makedep of `foo` in rare
cases bar would be listed as [aur make] even thought it was explicitly
requested.
Previosuly when reading from stdin we did not redirect back to the real
stdin afterwards so it was imposible to interact with y/n questions.
Now redirect back to "/dev/tty" just like pacman does.
