merge both dependency resolving parts into depSolver. The name was
choosen simply to not colide with the current code.
depSolver works but it not implemented in the install process and is
missing conflict checking.
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.
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.
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.
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.
Bash seperates on whitespace, so the fish completion file
actually works for bash and zsh. So remove the concept of shells
entirley and just use the singular aur_sh.cache file.
If for some reason output without the repository data is needed, the
user could always just pipe it into awk like so
`yay -Pc | awk '{print $1}'`. Or perhaps a --quiet option could be added
where yay will strip the output itself.
The completion cache now updates when installing AUR packages. This is
done as a goroutine with no wait groups. This ensures the program will
never hang if there is a problem.
The completion is stil updated during -Pc but as long as an AUR package
has been installed recently it should not need to update.
The cache will now also wait 7 days instead of 2 before refreshing.
A refresh can be forced using -Pcc.
When using nocombinedupgrade "there is nothing to do" is printed when
insinstalling repo packages. This is because as far as AUR
installer is concerned, there is nothing to do. Instead only print that
when doing a sysupgrade.
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.
Before:
* Empty line after `Searching AUR`
* `There is` starts with capital letter without space before
```
> yay --combinedupgrade -Syu
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
multilib is up to date
:: Searching databases for updates...
:: Searching AUR for updates...
:: Starting full system upgrade...
there is nothing to do
> yay --nocombinedupgrade -Syu
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
multilib is up to date
:: Starting full system upgrade...
there is nothing to do
:: Searching databases for updates...
:: Searching AUR for updates...
There is nothing to do
```
After:
```
> yay --combinedupgrade -Syu
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
multilib is up to date
:: Searching databases for updates...
:: Searching AUR for updates...
:: Starting full system upgrade...
there is nothing to do
> yay --nocombinedupgrade -Syu
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
multilib is up to date
:: Starting full system upgrade...
there is nothing to do
:: Searching databases for updates...
:: Searching AUR for updates...
there is nothing to do
```
When looking at diffs of packages downloaded as tar achives actually
show a diff instead of opening the files in the ediror. This diff
is against /var/empty so it is not that useful. In realiy this is an
excuse to move the srcinfo parsing back down to after the git merge.
Viewing the build files in the editor requires the .srcinfos to be
parsed to know what .install files are used. Now viewing diffs does not
need the srcinfos so they can be moved to after we git merge.
Before now the srcinfo would have been of the previous version. This is
not much of a problem because we don't really use the srcinfo for much.
Checking the arch and pgpkeys which never really change.
Recently libc++ changed their pgp keys and yay missed that because it
parsed the old srcinfo without the new keys.
Viewing a proper diff for tars can be tossed on the todo by doing
something along the lines of:
mv pkg{,.old}
diff pkg{,.old}
rm -rf pkg.old
But I doubt there are many people out there using tar so it's not much
of an issue.
Previously each call to an external command had two functions.
PassToFoo() and PassToFooCapture(). These functions are always similar
and end up with duplicated code.
So instead have the passToFoo() functions return the cmd itself and
create small helper functions show() and capture() which will run the
command and either forward it to std{out,err,in} or capture the output
Also the saveVCSInfo() function which was called after every makepkg
call is now only called after the pacman -U succeeds.
Currently When performing a system upgrade, Yay will first refresh the
database then perform the repo and AUR upgrade. This allows Yay to add
some features such as better batch interaction, showing potential
dependency problems before the upgrade starts and combined menus
showing AUR and repo upgrades together.
There has been discussion that this approach is a bad idea. The main issue
people have is that the separation of the database refresh and the upgrade
could lead to a partial upgrade if Yay fails between the two stages.
Personally I do not like this argument, there are valid reasons to Yay
to fail between these points. For example there may be dependency or
conflict issues during the AUR upgrade. Yay can detect these before any
installing actually starts and exit, just like how pacman will when
there are dependency problems.
If Yay does fail between these points, for the previously mentioned
reasons or even a crash then a simple refresh will not cause a
partial upgrade by itself. It is then the user's responsibility
to either resolve these issues or instead perform an upgrade using
pacman directly.
My opinions aside, The discussions on the Arch wiki has reached
a decision, this method is not recommended. So to follow the decided
best practises this behaviour has been disabled by default.
This behaviour can be toggled using the --[no]combinedupgrade flag
It should be noted that Yay's upgrade menu will not show repo packages
unless --combinedupgrade is used.
