Previously it was assumed that "git+https" means: use git and if that
fails fall back to https. What this actually means is just: use git over
https. Similary "git" just means use git and "git+http" means use git
over http.
Thus there is only ever one protocol to use. The current protocols array
has been kept for backwards compatibility with the vcs.json file. The
difference being now it will only ever place one protocol into the
array. Also when reading the array, the last protocol is always used.
This is so that entries that have not been regenerated will use the
correct protocol.
This message is proving to be more misleading than helpful. For
git+https sources, many hosts seem to always timeout when trying
ls-remote over git:// but then succeed on https://. This leads to
a time out message being displayed even though the URL was queried
successfully on the second try.
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.
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.
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.
Commit 474cc56f8d refactored the
getCommit() function to use the standard passToGit() and capture()
functions.
Unlike every other external call, here we use .Wait() and kill the
command after 5 seconds. This was missed and ended up breaking the
function.
So instead don't use capture but the manual .Wait() call. passToGit() is
still used.
There was a duplicate cmd.Run() that somehow went unnoticed. It was also
missing an error check, so it was in the code but had no ill effects.
In 86bfacd253 the error check was added.
This caused it to fail every time sure to the cmd already being ran.
Remove the duplicate cmd.Run() altogether.
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
Using a WaitGroup forced the code to wait for every goroutine to finish.
Using channels allows us to exit early if any of a packages sources need
an update. No point in waiting for the other requests to finish if we
know there is an update.
The update process was already partly parallel: repo, aur and devel
updates where each given their own goroutine.
This gives two further layers of parallelization. Firstly the
`needsUpdate()` function is now run in parallel for each package checked.
One package may have many vcs sources so `needsUpdate()` also checks all
of its sources in parallel.
This gives an aproxamte 3x speedup for `yay -Su --devel` timing from
when the command starts to when the number menu apears.
unfortunately git://bitbucket.org/volumesoffun/polyvox.git never
resolves on my machine for some reason so it always hits the 5 second
timout period.
It then moves on to http:/bitbucket.org/volumesoffun/polyvox.git/ which
does resolve as expected. I have not looked into it but I fear this
applies to all gitbucket repos. Luckly they are few and far between.
Use cacheHome for builddir instead of hardcoding ~/.cache
Use the command names in config.*Bin options.
For example PacmanBin is changed to just "pacman" this means yay will
call the pacman commit in PATH. If the user wants to use a different
binary they can still specify a full path in the config.
Use the command `git ls-remote <url> <branch>` to track devel updates
rather than relying on the GitHub API.
This allows devel update to work for every git based source and
elimantes the rate limiting from GitHub.
The yay_vcs.json format has changed to better support packages which
multiple vcs sources and to track the protocols each source uses. And
track the branch that each source tracks in it's fragment.