On Thu, 2025-06-19 at 18:28 +0000, AlphaLynx wrote: > Hi Bert, > > The purrcrypt package does not build from latest VCS sources. It > builds > from a specific pinned commit using a fragment in the source array > (currently 116f168 [1]). This follows the same pattern as packages in > the extra repo like yubikey-full-disk-encryption [2], wlr-protocols > [3], > rapidcheck [4], and others [5] that pin specific commits because > upstream does not yet have tags or release tarballs. In the case of > upstreams like this, the latest release version is the latest commit > to > the main/master branch that changes the package. For these upstreams > a > -git VCS package should use a development branch. So, when upstream > releases new commits on main that would change the package (if ever - > it's been inactive for months), I will manually update purrcrypt's > PKGBUILD to the new commit hash. This makes purrcrypt-git > functionally > identical to purrcrypt, as both would build the same commit. > > I've shared my more detailed thoughts on the VCS naming guidelines > and > why this is a duplicate in my comment on the purrcrypt package [5]. > Am I > understanding the guidelines correctly, or am I misinterpreting > something about when the -git suffix packages are useful? > > Could you reconsider based on this clarification? > > Kind Regards, > AlphaLynx
Hi AlphaLynx, Thanks for the clarification. The main repos do, indeed, on occasion create packages with a specific but arbitrary git commit, in absence of proper releases. This is often a necessity, as some more well-known and requested software depends on software that has no releases. Ideally we would use only "real" releases. A VCS package in the AUR automatically builds from the latest sources. Many AUR automations automatically recognise these and can check if they need to be rebuilt. Unless upstream changes the package in an incompatible way, e.g. they add some new dependencies, the -git PKGBUILD never has to be updated. The main repos cannot do that with our current infrastructure, as every package is built manually (or somewhat automatically) by one of the package maintainers, and shipped to the binary repos. These cannot be updated automatically, especially if their dependents need to be rebuilt as well. I do believe I correctly rejected your deletion request, as the VCS version is a correct VCS package, automatically building from the latest release. There is an argument to be made that the main package is _not_ a duplicate, since it's allowed to pin a specific, tested commit in absence of proper releases. [1] Nevertheless, I recommend you don't and accept the -git package. I do the same thing myself maintaining domjura-git [2] which has the exact same. I don't think upstream is going to add any releases ever, but the same PKGBUILD has worked, correctly, since 2017. I hope this helps, Bert. [1]: https://wiki.archlinux.org/title/VCS_package_guidelines [2]: https://aur.archlinux.org/packages/domjura-git
