I have edited my question for clarity.

TL;DR Will yay update a package I initially installed from my own local PKGBUILD when I update my PKGBUILD file? In other words, can AUR helpers be used for packages that are not in AUR?

Details: Say I create a PKGBUILD file locally and use it to install a package that is not in the AUR, using these steps:

Installing packages

  • Acquire the build files, including the PKGBUILD and possibly other required files, like systemd units and patches (often not the actual code).
  • Verify that the PKGBUILD and accompanying files are not malicious or untrustworthy.
  • Run makepkg -si in the directory where the files are saved. This will download the code, resolve the dependencies with pacman, compile it, package it, and install the package.

After I have followed the steps above to install a package without using an AUR helper, can I later keep the package updated with an AUR helper? Of course, since the package is not in the AUR, I will have to update my local PKGBUILD file when the developer releases a new version. Assuming I do this, will a good AUR helper (e.g., yay) be able to correctly run makepkg and pacman -U?

My motivation is to maintain the same workflow for these non-AUR packages, which means I wish to use an AUR helper to keep them updated.

My question is, more broadly, how do the AUR helpers determine when a package needs to be updated? Do they rely exclusively on the online repo or can they make that determination for a local package that is not in the AUR?

If the answer to that last question is yes, what steps do I need to follow when using my own local PKGBUILD? It is clear that I need to update my PKGBUILD file when a new version of the application is released. Do I need to put the PKGBUILD files in a certain location for a tool like yay to find them? Do I need to "register" the local PKGBUILD file with yay in some way? Do I need to follow a certain convention in regard to version numbers?

1 Answer 1


None of the tools you mentioned will do this automatically, becuase they all rely on someone, the package maintainer, to update the PKGBUILD for new releases. The only exception to this is VCS PKGBUILDs where they will, by default, pull the latest source.

AUR helpers read srcinfo to determine if a package has been updated. There is no magic at work, someone still has to make that, and any other necessary changes to the PKGBUILD, to trigger a rebuild/update.

You can write a script to update the PKGBUILD, but you are effectively assuming the maintainer role, so however you achieve it, you will have to update the PKGBUILD.

  • After reading your answer, I realized my question was not clear. I have revised it.
    – MountainX
    Commented Sep 19, 2018 at 19:26
  • @MountainX Updated the relevant section. Read the AUR article on the Arch wiki for the rest.
    – jasonwryan
    Commented Sep 19, 2018 at 20:04
  • AUR helpers read .SRCINFO files exclusively from the AUR online to determine if a package has been updated and to trigger a rebuild/update of the local package. A locally updated .SRCINFO and PKGBUILD file would not work with an AUR Helper. Correct statement?
    – MountainX
    Commented Sep 19, 2018 at 20:32
  • @MountainX You could create a custom repo, but that would be overkill for one PKGBUILD.
    – jasonwryan
    Commented Sep 19, 2018 at 20:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .