Normaly we only pass --config to pacman if the user specifies it on the
command line. Otherwise we let pacman use it's default config location.
If the user has changed pacmanconf in Yay's config file then this could
cause a miss match between the config we use to init alpm and the config
pacman is using.
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.
Currently we do not handle -Sp, this leads to yay trying a proper
install and failing. So instead pass it to pacman and exit. Ideally we
would extend -Sp to include AUR packages but for now don't bother.
As it turns out, the times you need root also tend to be the time you
need to manipulate the database. So the needWait() function can be
removed and repllaced by needRoot()
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.
--ask is no longer used when installing AUR packages, instead pass no
confirm when we know there are no conflicts and wait for manual
confirmation when there are.
This means that when there are no conflicts there should be no change in
behaviour and the user will not need to intervene at all.
The old behaviour can still be used with --useask.
Clean build needs to happen before downloading pkgbuilds so that they
can be deletd before downloading.
Editing and diff viewing needs to happen after downloading the
pkgbuilds.
Prevously we asked to clean and edit at the same time. Then clean,
download pkgbuilds and open the editor.
This poeses a problem for diff viewing and editing. It's likley that the
user will see the diff and use that to decide if they want to edit the
pkgbuild. Using the current method, the user will be asked to view diffs
and edit before actually seeing any diffs.
Instead split cleaning diff showing and editing to three seperate menus
in the following order:
show clean menu
clean
download pkgbuilds
show diff menu
show diffs
show edit menu
edit pkgbuilds
Also each menu is seperatly enableable. By default only the diff menu is
shows. If the user wishes to clean build, edit pkgbuilds or disable
diffs then the user can use the --[no]{clean,diff,edit}menu flags. This
replaces the --[no]showdiffs flags.
The order of targets does somewhat matter. For example doing something
like 'pacman -S db1/foo db2/foo' should cause the second package to be
skipped.
The order of targets also effects in which order they are resolved. This
should make errors more reproducable if any ever occur.
diff viewing can be toggled via --[no]showdiffs. When enabled diffs will
be shown for packages between the current HEAD and upstream's HEAD.
Packages downloaded via tarballs will be shown in full using the editor
git diff is used to show diffs. Therefore the pager for diffs can be
set via the PAGER and GIT_PAGER enviroment variables.
These flags limit operations to only check the repos or only check the
AUR. These flags apply to -S, -Si and -Su.
-a may also be used as a short option for --aur. --repo has no short
option as -r is taken.
-Sc will delete cached AUR data from Yay's build dir according to
the `CleanMethod` specified in the Pacman config file.
-Scc will delete all cached AUR data.
Additionally -Sc will also delete all untracked files in the AUR cache.
This will delete things such as downloaded sources and built packages
but will leave directories behind.
This is very usefull because the only reason a directoiry should exist
in the cache is because of downloaded VCS sources. Non VCS sources are
redownloaded every update because when a new version is released a new
tarball has to be downloaded. But VCS sources are never redownloaded,
updates are simply pulled. For this reason the user probably wants to
keep this data as it is still usefull even after building and installing
a package.
