yay v9.0.0 - libalpm v11.0.1
Updating devel packages does not update all git repos from the aur.
Install oh-my-zsh or any other package receiving Upstream updates, but not aur updates. Wait till Upstream has an update, and the yay will not pull.
In comparison, if you run yaourt -Su --aur --devel all of the dev packages get checked for an update.
yay -Syu --aur
:: Searching AUR for updates...
:: Checking development packages...
-> fsharp: local (10.1.2+2+g32505e203-1) is newer than AUR (4.5.0-3)
-> Out Of Date AUR Packages: biicode cmake-doc-qch serviio
there is nothing to do
yay checks the last commit on the remote repo with the installed package commit hash and only offers to update when the hashes don't match, which is different than how yaourt handles devel updates.
This hash cache is done in ~/.cache/yay/vcs.json by default. Normally it is updated at the end of the package install with the message Found git repo.
If you think yay is not offering you updates even though upstream devel has been updated this may have happened: If you transition between aur helpers and did not install the devel package using yay at some point then it is possible it never got added to the cache. yay -Y --gendb will fix the current version of every devel package and start checking from there.
To add: if you check the man page there is an example of how to perform a pacaur style --devel (for which i assume yaourt is similar).
I believe it is the same as pacaur style (at least I treated it as such, I'll still add part of my reply to the FAQ because it's not the first time I've seen this)
For the record, yaourt --devel is quite rudimentary. For comparison, pacaur --devel was different from yaourt --devel on the following points:
@rmarquis
it was usually used in conjunction with --needed, which updates the VCS clone sources, check source version, and recompile/install only if the new version is newer. Yaourt forces the recompile/install in all cases.
yaourt doesn't force recompile in all cases, only when the upstream git repo has new commits. If there are no updates upstream, here's what happens:
==> Continue building faba-icon-theme-git ? [Y/n]
==> ---------------------------------------------
==>
==> Building and installing package
==> Making package: faba-icon-theme-git 303.6f1cea3-1 (Mon 10 Dec 2018 09:
==> WARNING: Skipping dependency checks.
==> Retrieving sources...
-> Cloning faba-icon-theme git repo...
Cloning into bare repository '/tmp/yaourt-tmp-greg/aur-faba-icon-theme-git
remote: Enumerating objects: 14502, done.
remote: Total 14502 (delta 0), reused 0 (delta 0), pack-reused 14502
Receiving objects: 100% (14502/14502), 21.82 MiB | 14.05 MiB/s, done.
Resolving deltas: 100% (9996/9996), done.
==> Validating source files with sha256sums...
faba-icon-theme ... Skipped
==> Extracting sources...
-> Creating working copy of faba-icon-theme git repo...
Cloning into 'faba-icon-theme'...
done.
==> Starting pkgver()...
==> Updated version: faba-icon-theme-git 329.6d7ebd2-1
==> Sources are ready.
==> faba-icon-theme-git is already up to date.
My bad, thanks for the clarification! I guess I might be confusing with another helper, (or the fact I couldn't force a recompile?). I'm pretty sure about the dependency ordering though.
Why not try to use the pkgver() function to know if a new version is available?
@frealgagu pkgver being bumped assumes the AUR PKGBUILD maintainer does regular pushes. For git packages this in unreasonable.
But I'm not talking about pkgver variable. The pkgver function updates the variable using a makepkg, every devel PKGBUILD should have the function to update the version number. And it should work not just for git packages but for every vcs package without worry about save the last hash, just need to compare the result of pkgver function with the installed package to know if it should be upgraded.
As said there is a pacaur style devel command in the man page.