GIT PKGBUILD - how to deal with version? / Is my PKGBUILD OK?

MightyPork · 2014-10-03 12:03:29

I'm making a PKGBUILD that takes stuff directly from git.

I've - I think - managed to set pkgver based on git tag, but when I make a aur package with "mkaurball", it puts the current version in the name. Is that OK?
I don't want to have to make new aurball each time I make a new tag.

Here's my PKGBUILD - looks OK?

# Maintainer: Ondřej Hruška <ondra@ondrovo.com>

pkgname='sdscp'

pkgver=1.3.2
pkgrel=1

pkgdesc="External preprocessor and pre-compiler for SDS-C (by AN-D.cz)"
arch=('any')
url='https://github.com/MightyPork/sdscp'
license=('GPL2')

depends=('python3')

makedepends=('git')

source=('git+https://github.com/MightyPork/sdscp.git')
provides=('sdscp')
md5sums=('SKIP')

pkgver() {
  cd "${srcdir}/${pkgname}"
  git describe --tags | sed 's|-|.|g'
}

package() {
  # install license
  install -Dm 644 "${srcdir}/LICENSE" "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"

  # install files in /usr/share
  # install -d "${pkgdir}/usr/share/${pkgname}/"
  mkdir "${pkgdir}/usr/share/${pkgname}/"

  cp -pR ${srcdir}/${pkgname}/* ${pkgdir}/usr/share/${pkgname}/

  # chmod +x "${pkgdir}/usr/share/${pkgname}/sdscp.py"

  # install link in /usr/bin
  mkdir -p "${pkgdir}/usr/bin/"
  ln -s "/usr/share/${pkgname}/sdscp" "${pkgdir}/usr/bin/sdscp"
}

Last edited by MightyPork (2014-10-03 12:03:55)

drcouzelis · 2014-10-03 12:23:27

I think the name of the package should show that it is a git packages:

pkgname='sdscp-git'

I'm sorry, I don't remember exactly how to make a PKGBUILD file for a git package, but if you follow the git PKGBUILD template in "/usr/share/pacman" then you should be fine.

EDIT: Apparently we should NOT be using the templates at the moment...

Last edited by drcouzelis (2014-10-03 12:51:59)

MightyPork · 2014-10-03 12:24:47

drcouzelis wrote:

I think the name of the package should show that it is a git packages:
pkgname='sdscp-git'
I'm sorry, I don't remember exactly how to make a PKGBUILD file for a git package, but if you follow the git PKGBUILD template in "/usr/share/pacman" then you should be fine.

Yeah, it will be sdscp-git. So the rest looks OK?

tomk · 2014-10-03 12:41:13

Don't use the /usr/share/pacman template - it's way out of date, and no longer accurate. The VCS PKGBUILD Guidelines in the wiki are current, you should apply them to your package.

Scimmia · 2014-10-03 15:21:16

Yes, it's OK. There are a couple of minor things that could be changed, but it should work fine.

stevenhoneyman · 2014-10-03 16:47:00

Personal preference - add the date of the commit to the version string.
e.g.

$ git log -1 --format=%cd.%h --date=short|tr -d -
20140723.77fea8b

vs.

$ git describe --tags | sed 's|-|.|g'
fatal: No names found, cannot describe anything.

Reasons include:

- tags can be forgotten or don't always sort well
- git commit short hash is meaningless at a quick look, but good to be able to reference if needed
- standard format, iso date will always sort and version properly

just my opinion though

Last edited by stevenhoneyman (2014-10-03 16:50:29)

progandy · 2014-10-03 16:54:03

MightyPork wrote:

I've - I think - managed to set pkgver based on git tag, but when I make a aur package with "mkaurball", it puts the current version in the name. Is that OK?
I don't want to have to make new aurball each time I make a new tag.

If you just want to provide the package in the AUR, then you don't have to create a new aurball for new tags.
If you want to support the update search of AUR helpers like cower, pacaur or yaourt, you'll have to upload a new aurball each time. Since you create new tags you could add a script that modifies the PKGBUILD, packs it and uploads it to the aur. There is e.g. Xyne's aurploader tool to help with that.

Last edited by progandy (2014-10-03 16:56:17)

WorMzy · 2014-10-03 16:58:44

Indeed. If people are going to use *-git packages, it's their responsibility to track upstream tags/commits and recompile as necessary.

Scimmia · 2014-10-03 17:50:02

stevenhoneyman wrote:

Personal preference - add the date of the commit to the version string.
e.g.
$ git log -1 --format=%cd.%h --date=short|tr -d -
20140723.77fea8b
vs.
$ git describe --tags | sed 's|-|.|g'
fatal: No names found, cannot describe anything.
Reasons include:
- tags can be forgotten or don't always sort well
- git commit short hash is meaningless at a quick look, but good to be able to reference if needed
- standard format, iso date will always sort and version properly
just my opinion though

Bad idea. Date does nothing to give you version information, it's not stable as the last commit can be before the previous commit, multiple commits on the same day will break the pkgver, etc.

stevenhoneyman · 2014-10-03 20:14:04

Scimmia wrote:

stevenhoneyman wrote:
Personal preference - add the date of the commit to the version string.
e.g.
$ git log -1 --format=%cd.%h --date=short|tr -d -
20140723.77fea8b
vs.
$ git describe --tags | sed 's|-|.|g'
fatal: No names found, cannot describe anything.
Reasons include:
- tags can be forgotten or don't always sort well
- git commit short hash is meaningless at a quick look, but good to be able to reference if needed
- standard format, iso date will always sort and version properly
just my opinion though
Bad idea. Date does nothing to give you version information, it's not stable as the last commit can be before the previous commit, multiple commits on the same day will break the pkgver, etc.

I do include the commit hash(short) to avoid multiple commits on the same day breaking anything.

Scimmia · 2014-10-03 22:24:25

But since the hash is psudo-random, you end up with a pkgver going up and down constantly within a given day.

Trilby · 2014-10-03 22:53:03

I just use the commit number. No need for tags or other fancywork. Generally I assign a more standard major version number, use the commit number as a minor version, and tack on the hash as a subversion:

echo "4.$(git rev-list --count HEAD).$(git describe --always )"

progandy · 2014-10-03 22:59:42

The date is a poor choice for a version number in a git package. The wiki page about VCS PKGBUILDs does the right thing and uses version tags with revision count after the tag. If you get a lot of bad tags or there are none, use revision count since the beginning of the branch. In order to simplify the identification, append the (abbreviated) commit hash.
https://wiki.archlinux.org/index.php/VC … elines#Git

Scimmia · 2014-10-03 23:15:05

Trilby wrote:

I just use the commit number. No need for tags or other fancywork. Generally I assign a more standard major version number, use the commit number as a minor version, and tack on the hash as a subversion:
echo "4.$(git rev-list --count HEAD).$(git describe --always )"

Please do not do this. If you want the short hash, use git rev-parse --short HEAD, git describe --always will change once the author creates a tag and completely screw up your versioning.

Even better if you pull that major version from somewhere.

Last edited by Scimmia (2014-10-03 23:16:24)

Trilby · 2014-10-03 23:20:48

Eh ... I am the author. And I don't use tags. But that command seems to work great too. Whatever used to be on the wiki failed on all my git repos, so I went with what worked.

Last edited by Trilby (2014-10-03 23:27:20)

Arch Linux

#1 2014-10-03 12:03:29

GIT PKGBUILD - how to deal with version? / Is my PKGBUILD OK?

#2 2014-10-03 12:23:27

Re: GIT PKGBUILD - how to deal with version? / Is my PKGBUILD OK?

#3 2014-10-03 12:24:47

Re: GIT PKGBUILD - how to deal with version? / Is my PKGBUILD OK?

#4 2014-10-03 12:41:13

Re: GIT PKGBUILD - how to deal with version? / Is my PKGBUILD OK?

#5 2014-10-03 15:21:16

Re: GIT PKGBUILD - how to deal with version? / Is my PKGBUILD OK?

#6 2014-10-03 16:47:00

Re: GIT PKGBUILD - how to deal with version? / Is my PKGBUILD OK?

#7 2014-10-03 16:54:03

Re: GIT PKGBUILD - how to deal with version? / Is my PKGBUILD OK?

#8 2014-10-03 16:58:44

Re: GIT PKGBUILD - how to deal with version? / Is my PKGBUILD OK?

#9 2014-10-03 17:50:02

Re: GIT PKGBUILD - how to deal with version? / Is my PKGBUILD OK?

#10 2014-10-03 20:14:04

Re: GIT PKGBUILD - how to deal with version? / Is my PKGBUILD OK?

#11 2014-10-03 22:24:25

Re: GIT PKGBUILD - how to deal with version? / Is my PKGBUILD OK?

#12 2014-10-03 22:53:03

Re: GIT PKGBUILD - how to deal with version? / Is my PKGBUILD OK?

#13 2014-10-03 22:59:42

Re: GIT PKGBUILD - how to deal with version? / Is my PKGBUILD OK?

#14 2014-10-03 23:15:05

Re: GIT PKGBUILD - how to deal with version? / Is my PKGBUILD OK?

#15 2014-10-03 23:20:48

Re: GIT PKGBUILD - how to deal with version? / Is my PKGBUILD OK?

Board footer