As mentioned it is possible for stuff to clash in cache if you were to
-G a package from the repos, then -S an AUR package by the same name. To
avoid that give abs cloning its own directory.
It is still possible for a clash to occur if there was a package named
abs. However currently there is not.
Idealy the aur cloning would also get it's own subdir, but that will
invalidate everyone's cache so leaving it for a time with more breaking
changes.
This is also under its own config option so that AURDEST does not
interfere with it.
This reverts commit 6cd47dd83c49689f0bd84c650feea9c71ed1aaf2, reversing
changes made to 16fddae8b6e5b0adb0265f4f8f44bff607394dcc.
Signed-off-by: Jguer <me@jguer.space>
After building an AUR package don't install it right away. Instead queue
it for install.
Then when a package comes along that does not have all of its
dependencies satisfied, install the queued packages before builting.
This allows a standard AUR update to be done with one transaction, while
building AUR packages with long dependency chains will work as normal.
This feature is behind the `--batchinstall` flag.
If the package is already installed, we need to check if it is in the
repos to see if it aplies to rebuild tree. Normally alpm will not prompt
us to select a provider if we already have one installed. An exception
comes up when we have a provider installed that is from the AUR. In this
case FindSatisfier() still asks us to select a provider.
Now make sure to never to never show the menu if the package exists in
the local repo.
Previous default SigLevels caused 3rd party databases to take a very long time to
load and also to not load properly. Probably due to missing keys(?).
Pacman takes a long time to check the databases. For now, always set to
SigLevel 0 like how go-alpm did in its config parsing. Needs more
looking into for a proper fix.
This moves the config parsing from out of alpm and into the
go-pacmanconf libary plus some boilerplate code to get it into our alpm
config.
This makes sense as many config options such as UseColor and CleanMethod
have nothing to do with alpm and only relate to pacman.
pacman-conf is used instead of direct config parsing. This tool resolves
defaults and includes for us, so we don't need to handle it.
It is now safe to drop all the config parsing from go-alpm.
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.
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.
