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.
A while ago the url to download a pkgbuild was using pkg.Name(), it was
latter changed to pkg.Base() to support split packages. It seems that
pkg.Base() does not work for non split packages for some reason.
So instead try pkg.Base() and if it is empty default to pkg.Name().
Also add support for downloading from multilib
Adds the ability to pick which database to install a package from. This
is extended to also support for AUR packages. For example `extra/git`
and `aur/yay` should both work`. When not explicitly requesting
a database repo packages will be choosen over the AUR.
This features extends to yogurt mode, listings where a package shows up
in multiple database/the AUR is now handled.
The aur does not have a real pacman databse like core, extra ect. But
can be accessed as if was one with `aur/name`. Using Yay with a pacman
repository named "aur" is undefined.
commit 5286f385 broke the alignment on -> in the upgrade menu.
This commit moves the function responsable for printing the upgrade menu
from upgrade.go to print.go, fixes the formating to how it was before
and changes the padding on the number to three digits instead of two.
This allows proper alignment on numbers >100 which is not unheard of.
With the planned move to number menus for askcleanbuilds and
askeditpkgbuilds a consistant way is needed to make number menus in
a clean way without rewriting the same code over and over.
The prevous commit introduced `parseNumerMenu()` to create a standard
way to handle number menus. This commit implements the new function for
the upgrade menu both as a test and to bring some new features.
Entering 1-9999999 will no longer cause ram usage to spike to 100%
(before yay would try to build an []int containing the numbers 1 to
9999999).
Suport for discarding/including entire repos by name
> "54 aur extra"
would skip the package numbered 54 and all packages
that are listed as aur and extra.
> "^devel ^20"
would only install packages listed under devel and the package
numbered 20
With this The user should never have to manually edit the yay config
file. All options can be set directly through yay using
`yay --<option> <value> --save`
