depOrder.Aur contains the order in which AUR packages are to be
installed. While depOrder.bases contains the actual package data
organized by pkgbase.
deoOrder.AUR is kind of counterintuitive, as it only contains one
package from each package base.
For example if you were to install libc++{,abi,experimental},
depOrder.Aur would only contain one of those packages, which one
actually being quite random. depOrder.Bases[pkg.Pkgbase] will then be
looked up and everything under that slice would be installed.
This means that the only real use depOrder.Aur has, is to give the
pkgbase. So to cut out the middleman, lets merge .Aur and .Bases into
a single field.
Doing this has also heped to spot som subtle bugs:
Fix subtle split package errors.
The number menus now correctly list and respect (installed) for bases
that have atleast one of their packages installed.
Entering package names in number menus now always expects the pkgbase
name instead of the random package which happened to make it into .Aur.
--rebuild and --redownload correctly handles split packages.
formatPkgbase is also used more.
Only pass the packages belonging to the desired pkgbase. Before our
entire list of every pkgbase had to be passed, as well as an example
package from the base we are looking for.
This lets use use formatPkgBase easier in other places outside of
install.
Many of the functions in install could also be simplified in a similar
way, although that has not been done in this commit.
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.
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
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.
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.
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]).
