Arch Linux User Repository

@Chinaboy5216 do not mark VCS packages as out of date.

I found this topic https://www.reddit.com/r/archlinux/comments/a030v7/how_do_you_manage_git_aur_packages/ Seems like people do in a way similar to described by you.

We've posted simultaneously. I accept your answer then. Thank you for your time. I hope it's ok to have this slightly offtopic here.

The rationale is that VCS AUR packages would constantly need their PKGBUILDs updated, which would be a waste of time and would also overwhelm aurweb. Although this is not explicitly stated, this section of the Arch User Repository wiki page indicates that AUR maintainers of VCS packages should not commit mere pkgver bumps.

Therefore, the onus is on end-users to check for updates to VCS AUR packages and re-run makepkg as they see fit. There are dozens of different tools available for tracking updates - pacvcs is one that is specific to VCS packages in the AUR, but if you were looking for a more popular choice, then I would look into nvchecker.

@morgenstern At least it seems that I understand this versioning machinery correctly.

Sorry to keep bothering you, but could you link me some info about an agreement on this approach where maintaining VCS-based package updates is the end-user's responsibility, it feels counter-intuitive to me.

From another point of view, having to update the git version manually allows the package maintainer to assure that the update breaks nothing. So each maintainer does his little part. Otherwise, the burden of tens or hundreds of packages validity check drops on a single end-user. Also, it may slow down the update process (in theory).

And https://aur.archlinux.org/packages/pacvcs seems to have stunningly low popularity for such a seemingly important package (if your ideology (if I understand it correctly) is supported by the community).

Probably will ask for opinions on this topic on IRC later.

You will need to check if there are new commits and then rebuild the package if desired. Personally, I use the AUR packages pacvcs in a pacman hook so that I can see which VCS AUR packages need updating when I run pacman -Syu.

@morgenstern I read that whole guideline. What I see is that it will get the latest version during installation. I can't see it saying that it will update AUR PKGBUILD.

The problem is how it will know that there is a newer version prior to installation by running something like pacman -Syu when PKGBUILD has not been changed (hence package databases).

Or maybe there is some step to check all locally installed packages that are VCS-based? I only can see the message Synchronising package databases, it doesn't sound like it would do something like that. Maybe because I used yay.

Just checked this article. It even suggests using some utils to be notified about new releases. Again, I don't see any automation in updating the version. https://wiki.archlinux.org/title/Arch_package_guidelines#Working_with_upstream

@furioness This package complies with the Arch VCS package guidelines and uses the pkgver() function to update pkgver when invoked by makepkg:

pkgver() {
  cd "${_pkgname}"
  git describe --long --tags | sed 's/\([^-]*-g\)/r\1/;s/-/./g'
}

I had ver 0.90.40 when the current is 0.90.47 or something like that. I tried to install cherrytree-git just to notice that I already had the git version (e.g. this one). Reinstalling do the deal, but this way denies the point of being under a package manager that keeps packages up to date. So, despite this one being git-based, it looks outdated to me.

I checked the first git-based package that got in my sight to see if it has the same problem. https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=scsi2sd-v6-git As you can see, it has pkgver variable, so the package manager can see that there is a newer version.

So, I suggest you add some kind of pkgver variable. Sorry if I misunderstand something. Thank you for maintaining.

To my happy surprise this created automagically a newer version, 0.99.44 Thanks!

Tests are now built and run separately and are not optional.

If building in a clean chroot, see here and here for allowing chroot access to your X server.