Conventional method of producing -git packages
Hello, I am pretty new to the AUR, however I have read through the arch wiki and this question is not really referenced there. I have seen some -git packages which update the package on each new commit to master, which is what I thought -git packages should aim to do, however I have seen others which only do it for every 5 or so commits to save time. However I have also seen another method, of just not bumping the package version and have the package clone master and then append the latest git commit to the package name when building it. What is the actual conventional method of producing a -git package for a piece of software? Thank you, Polarian
On Tue, 6 Dec 2022 13:34:05 +0000 Polarian <polarian@polarian.dev> wrote:
Hello,
I am pretty new to the AUR, however I have read through the arch wiki and this question is not really referenced there.
I have seen some -git packages which update the package on each new commit to master, which is what I thought -git packages should aim to do, however I have seen others which only do it for every 5 or so commits to save time.
However I have also seen another method, of just not bumping the package version and have the package clone master and then append the latest git commit to the package name when building it.
This is how -git packages work. If it doesn't do this but uses a pinned commit instead, it's not a -git package. The version displayed in the AUR doesn't matter. The people bumping the pkgver every commit or every 5 commits or whatever are just wasting their time, and annoying their users.
What is the actual conventional method of producing a -git package for a piece of software?
Thank you, Polarian
If you are building a package that tracks the master branch of git, you want to build the latest version of it. You could also track various branches or tags in the package as well. In each case, the assumption is that you would want to build the latest commit in that branch. This is mostly useful for developers testing their software or the latest feature. On my packages in aur I will bump the version if I am tracking a new stable branch, or a particular feature has been implemented and proven to be stable. On Tue, Dec 6, 2022, 14:42 Doug Newgard <dnewgard@outlook.com> wrote:
On Tue, 6 Dec 2022 13:34:05 +0000 Polarian <polarian@polarian.dev> wrote:
Hello,
I am pretty new to the AUR, however I have read through the arch wiki and this question is not really referenced there.
I have seen some -git packages which update the package on each new commit to master, which is what I thought -git packages should aim to do, however I have seen others which only do it for every 5 or so commits to save time.
However I have also seen another method, of just not bumping the package version and have the package clone master and then append the latest git commit to the package name when building it.
This is how -git packages work. If it doesn't do this but uses a pinned commit instead, it's not a -git package.
The version displayed in the AUR doesn't matter. The people bumping the pkgver every commit or every 5 commits or whatever are just wasting their time, and annoying their users.
What is the actual conventional method of producing a -git package for a piece of software?
Thank you, Polarian
Hi, to my knowledge, if it's for an explicit branch, that doesn't change, you bump pkgrel, to build against updated dependencies. If you provide a package building the last commit, you usually don't do anything. If a user does build the package, pkgver does change automatically. It's an annoyance, if maintainers change pkgver for no other reason, than to follow the latest commits. You only change pkgver, if the PKGBUILD changed, because a new commit requires different dependencies or something like this. As long as the PKGBUILD is the same, you don't change pkgver. Regards, Ralf
Hello, So if you are building against static/specific commits, you should bump the package version every commit, however say if it is an aur package to just build the latest code in the master branch, you just let it roll and do not bump the version, correct? This brings up one question, a lot of people use AUR helpers, they detect updates in package versions, if this is not updated, doesn't this break AUR helpers? Thank you, Polarian
AUR helpers are generally considered unsupported, however some of them provide a configuration option to rebuild VCS packages every x days, which solves this specific issue.
Hello, I made a suggestion to another arch user which I believe breaks the rules of the AUR, but I do not see why there can't be an addition to the AUR to specify if the package is a git package, and if so it fetches the latest commit hash of the package every x hours and dynamically bumps itself, obviously without emailing the user because that would suck. I believe this issue could be improved massively, because currently in order to maintain git packages, I got to check their git repos every few days to make sure there ain't any updates, it defeats the purpose of package managers/AUR helpers which kinda sucks. I guess if I am so interested in this I should PR the AUR source code with the feature. Thanks for the help, Polarian
Hi, at least yay [1] has a feature which does exactly this. It fetches the upstream repos of VCS packages when it's told to look for updates and then also suggests updating the VCS packages, if there are new commits upstream since the last rebuild. Glad to help j.r [1] https://github.com/Jguer/yay
Hello, there is actually a wiki page covering exactly that at this link: https://wiki.archlinux.org/title/VCS_package_guidelines
participants (6)
-
Doug Newgard
-
Evert Vorster
-
j.r
-
Kusoneko
-
Polarian
-
Ralf Mardorf