[solved] git based package without git suffix possible?

loh.tar · 2025-07-14 19:38:47

I think the wiki says to always use the git suffix, even if I can't find the place right now. But the giudlines offer at least one exception, "..unless the package fetches a specific release." The suffix rule is also absolutely useful to distinguish between a regular release package and a git version package.

For my new project, however, I have decided to dispense with the usual tags and instead update the version number with every git push. So there will be no normal packages for the time being. If something should change in the future, the AUR could easily be adapted without leaving a AUR-git that is no longer needed.

Here is my draft. I have left out 'coreutils' in the depends array, IIRC not needed.

# Maintainer: loh.tar <loh.tar at googlemail dot com>
pkgname='folsy'
pkgver='25.7'
pkgrel='1'
pkgdesc="folder synchronization in POSIX sh"
arch=('any')
url="https://github.com/loh-tar/$pkgname"
license=('GPL-3.0-or-later')
depends=('findutils' 'grep' 'rsync' 'sed')
optdepends=('openssh: ssh support')
makedepends=('git')
source=("git+${url}.git")
sha256sums=('SKIP')

pkgver() {
	cd "$srcdir/${pkgname}"

	local _folsyVers
	_folsyVers=$(grep "^Version=.*readonly Version" folsy | cut -d'"' -f2)
	# _folsyVers should always be new and unique, but there is still murphy's law
	printf "%s.r%s" "$_folsyVers" "$(git rev-list --count HEAD)"
}

package() {
	cd "$srcdir/${pkgname}"
	install -pDm755 folsy "$pkgdir/usr/bin/folsy"
	install -pDm644 folsy-manual.txt "$pkgdir/usr/share/doc/folsy/folsy-manual.txt"
}

Last edited by loh.tar (2025-07-15 10:34:19)

seth · 2025-07-14 20:48:11

Unless your updating the AUR w/ every git commit, the version listed there will not reflect what the user actually builds.

Scimmia · 2025-07-14 21:01:00

The -git suffix is required here, as you're building from HEAD and dynamically generating pkgver.

loh.tar · 2025-07-15 06:37:16

Thanks for your help!

I'm a little confused. To what extent does the git-suffix change your objection? The automatic generation of the version is shown this way in the wiki. Do you generally always have to update a git-AUR or does the AUR-server (I'm sorry, hope you can follow what I mean) do it for you through the git extension?

seth · 2025-07-15 06:43:43

The -git suffix indicates that the package will build whatever is the git HEAD

You'd have to constantly align and update the PKGBUILD on the AUR w/ every git push to github.com/loh-tar/folsy
https://wiki.archlinux.org/title/AUR_su … ge_content

What exactly is the problem about appropriately naming the package as folsy-git?
If you want to "occupy" folsy, just add an AU package of that name that checks out a specific revision and every now and then update that PKGBUILD to check out a newer one.
I doubt that such would however be required, notably not as long as there's no upstream release at all.

loh.tar · 2025-07-15 08:07:48

The -git suffix indicates that the package will build whatever is the git HEAD

So, it's only a user hint, no technical necessity? In this case would a pkgver='latest-git-head' (or similar) do the same.

Your link wrote:

Do not commit mere pkgver bumps for VCS packages. They are not considered out of date when the upstream has new commits. Only do a new commit when other changes are introduced, such as changing the build process.

Isn't that exactly the opposite of what you are advising me to do? And VCS-Versioning reads to me that you should only change the version number if something fundamental, such as the build process, has changed.

There is even theTip: --holdver can be used to prevent makepkg from updating the pkgver but a short test has no effect with my PKGBUILD. Could the pkgver in some function be restored after the packages was build but before the file is rewritten? Because I would really like to set pkgver='git-head' and would have one thing less to care about.

What exactly is the problem about appropriately naming the package as folsy-git?

This has the air of something special, but it's supposed to be the official package

seth · 2025-07-15 08:45:53

So, it's only a user hint, no technical necessity? In this case would a pkgver='latest-git-head' (or similar) do the same.

It's a convention and mandated by the AUR submission guidelines.
Also this has nthing to do w/ the pkgver in the PKGBUILD, VCS AUR packages are supposed to be suffixed -git

Isn't that exactly the opposite of what you are advising me to do

Yes, but your plan is to NOT provide a VCS package. You're just building out of git where the package version randomly hapens to align w/ the git HEAD of the day.

Because I would really like to set pkgver='git-head' and would have one thing less to care about.

Good. Submit folsy-git then. Whatever you set as that variable will get replaced by pkgver() for the actual package anyway, but you likely want to stick w/ the build version you've when submitting/updating the PKGBUILD instead of some generic term that might confuse some AUR helper.

This has the air of something special, but it's supposed to be the official package

No and there's no such thing as an "official package".

loh.tar · 2025-07-15 09:44:39

So if i understand correctly after your first comment,..

Unless your updating the AUR w/ every git commit, the version listed there will not reflect what the user actually builds.

and now

Yes, but your plan is to NOT provide a VCS package. You're just building out of git where the package version randomly hapens to align w/ the git HEAD of the day.

I can upload this almost as it is (only change pkgver=25.7.r11 ), but need to update the PKGBUILD after a project update.

Lone_Wolf · 2025-07-15 10:12:02

You have 2 choices :

A.
make a package that always builds the same version.
pkgname would be folsy.
the source array needs to include the hash for the specific commit you want users to build, like

source=(git+/https://github.com/loh-tar/folsy.git#commit=cdcde50e436eb2c59eb6edc11cc0635ec5250509)

B.
Create a package that always builds the latest commit available.
pkgname would be folsy-git with

source=(https://github.com/loh-tar/folsy.git)

A is a stable package, B is a VCS package.
Both use git to retrieve sourcecode.

Edit: typo in url

Last edited by Lone_Wolf (2025-07-16 11:45:17)

loh.tar · 2025-07-15 10:33:20

Aha, that sounds kind of logical. Thanks for the detailed code examples!

Nevertheless, the concept of the vcs package seems to me to be implemented incorrectly. Will mark as solved.

Thanks to all for your time!

Arch Linux

#1 2025-07-14 19:38:47

[solved] git based package without git suffix possible?

#2 2025-07-14 20:48:11

Re: [solved] git based package without git suffix possible?

#3 2025-07-14 21:01:00

Re: [solved] git based package without git suffix possible?

#4 2025-07-15 06:37:16

Re: [solved] git based package without git suffix possible?

#5 2025-07-15 06:43:43

Re: [solved] git based package without git suffix possible?

#6 2025-07-15 08:07:48

Re: [solved] git based package without git suffix possible?

#7 2025-07-15 08:45:53

Re: [solved] git based package without git suffix possible?

#8 2025-07-15 09:44:39

Re: [solved] git based package without git suffix possible?

#9 2025-07-15 10:12:02

Re: [solved] git based package without git suffix possible?

#10 2025-07-15 10:33:20

Re: [solved] git based package without git suffix possible?

Board footer