Before --needed was left purerly to pacman. The problem with this is
that if a package is not in the cache, it will end up being build just
for pacman to skip over the install.
Now Yay will handle this and skip the build and install if --needed is
used. The inital clone and pkgver bumb is still donw.
The one place this function is used, the caller converts its data to
a map just to getBases will accept it. Instead just allow it to take the
slice to begin with.
There was a possibly that getIncompatible could be broken when working
with split packages. After looking into it, this does not seem to be the
case, as long as we only work with pkgbases.
arch may be overriden inside of a package function. The global arch
array may be 'any' but package_foo could say arch=('x86_64'). If you
were running arm then should yay warn about this?
I have decided the answer is no. This is because makepkg doesn't care.
It would seem makepkg only checks the global arch array. This leads me
to believe that the global array should contain a the required arch.
Therefore the correct way to do the former example would be to declare
the global arch as 'x86_64' and then override package_bar with 'any'.
So all that we should do is properly use formatPkgbase to list all the
packages under the base.
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.
Most programs seem to take an empty string as being the same as unset.
Even if they are technically different. This makes it easier to unset
variables via `VARIABLE= yay --foo`.
Split functions out into smaller, more simple chunks. Ensure the correct
order of things.
Before, initConfig() would also create config.BuildDirbefore
the command line flags have been applied, so yay would
try to mkdir what was in the config, ignoring the flag.
The current check involves checking the entire source url for the word
git. This can lead to yay asumming sources are git repos when they are
not.
For example: https://raw.githubusercontent.com/ryanoasis/nerd-fonts/v2.0.0/LICENSE/
Makepkg seems to also only respect the protocols. For example:
https://github.com/jguer/yay
will be fetched as a web page. git:// or git+https:// would be needed.
Although this does not seem to work the way yay assumes. You can not simply
+ togther a bunch of protocols. For exaplle: git+http+https:// will not
work, even though individually they do. git must also come first:
https+git:// will not work either.
Yay's method of spliting on each + is fine though, it works and I'm not
going to worry about broken packages that do https+git:// or similar.
I've seen `yay -Syua` given as an example all over the place. I'm not
sure if this is left over as a habbit from yaourt. In yay, -a restricts
the upgrade to AUR packages ONLY while I believe in yaourt it means to
also include the AUR.
The problem with `yay -Syua` is that you are doing a database refresh
and then only upgrading the AUR packages. Essencially:
pacman -Sy && update-aur
This is a recipy for partial upgrades.
Either upgrade everything `yay -Syu` or just the AUR `yay -Sua`.
Yay's dependency resolving takes provides into account. When upgrading
AUR package 'foo', if a repo package provides 'foo' then yay would get
confused and pull in the package providing 'foo' instead of the AUR
package.
This commit ensures AUR upgrades always exclusively check the AUR.
morganamilo