Arch Linux User Repository

@FabioLolix The problem with adding a commit hash to the package version is the following: 1.) The package version will refer to a specific commit while the actual repository contains newer commits (I don't think any maintainer would sync packages on commit level). 2.) Commit-specific versions will cause more updates than necessary. 3.) Many repositories do not ensure stability on each commit. 4.) This specific application does not contain any changes to the code or the resulting binaries in any newer commits than the version currently used.

So I don't see the practical usecase of making the version looking to be more specific while being potentially more inaccurate if new commits would come to the repository. It's pretty much like this: If the repository doesn't get any code changes, the version is practically correct. If it gets newer changes, a more specific commit-version-string would be incorrect.

The guidelines you referred to only state that "maintainers should favor a pkgver that makes sense" which I would agree with. However I don't see these guidelines as strict rules.

What I could agree on would be enforcing the state of code being consistent with the version by checking out the exact commit with the latest tag. Because that should ensure stablity but like I said before this project is pretty much frozen in development. So there isn't real urgency.

About the arch specifier it's quite simple in my opinion. If anyone proofs me wrong that this package won't build on a specific architecture, I will change 'any'. Otherwise I don't see how compiling from source would not be architecture independent in this case. Like I said, it doesn't use architecture specific features during compilation from my knowledge.

For supporting all the CPU archs, add all the CPU archs arch=(x86_64 i686 i486 pentium4 arm armv6h armv7h aarch64), which was present time ago https://aur.archlinux.org/cgit/aur.git/commit/?h=cadet-gtk-git&id=ecddf90cbdc98f0ec72afe14b1a7aa35406760a5

• $ namcap cadet-gtk-git-0.6.1-1-any.pkg.tar.zst

• cadet-gtk-git E: ELF file ('usr/bin/cadet-gtk') found in an 'any' package.

• https://wiki.archlinux.org/title/Arch_package_guidelines#Architectures

Letargic development is not an excuse to use a not proper pkgver()

@FabioLolix Since the build-script doesn't use any arch specific flags, there shouldn't be a restriction about the architecture as long as all dependencies are supported.

The package version isn't fully correct in terms of the commit hash is missing showing changes since last official tag. However the project is frozen in development. So the need to change this isn't huge. The examples for a valid pkgver() function are no requirement.

This pkgbuild need a proper pkgver(), see https://wiki.archlinux.org/title/VCS_package_guidelines#The_pkgver()_function

cadet-gtk is written in C, compiled packages will be CPU arch specific; can't be an 'any' arch package