[aur-general] PKGBUILD review request: libdime-hg
Hi everyone, I've just started writing some PKGBUILDs for some programs that are not present neither in the official package repository nor in the AUR. Specifically, I've packaged libdime [1] as a required dependency for the X-Plane developer tools [2].
I'm attaching the PKGBUILD below - if someone on this list could review it, that would be much appreciated. I've also got the following questions: 1) Is it correct to name the package "libdime-hg" only because its sources are checked out from a Mercurial repository (that's because no official tarballs exist any more - the Debian copyright file for the library [3] points to a now dismissed FTP site [4]), or should I just name it "libdime"? 2) On the same note, assuming that naming the package "libdime-hg" is correct, does it make sense to put provides=("${pkgname%-hg}") conflicts=("${pkgname%-hg}") in the PKGBUILD? I've thought to put these two lines as "safeguards" in case I need to distinguish between a libdime VCS and non-VCS package in the future.
Cheers and thanks in advance, Alessandro Menti
[1] https://bitbucket.org/Coin3D/dime [2] http://developer.x-plane.com/tools/ [3] http://metadata.ftp-master.debian.org/changelogs/main/d/dime/dime_0.20111205... [4] ftp://ftp.sim.no/pub/snapshots/
----- The PKGBUILD follows: -------------------------------------------- # Maintainer: Alessandro Menti <alessandro dot menti at hotmail dot it> pkgname=libdime-hg pkgver=r187.7cd55bc6a6d0 pkgrel=1 pkgdesc="A DXF (Data eXchange Format) file format support library" arch=('i686' 'x86_64') url="https://bitbucket.org/Coin3D/dime" license=('BSD') depends=('gcc-libs') makedepends=('doxygen' 'mercurial') provides=("${pkgname%-hg}") conflicts=("${pkgname%-hg}") source=("${pkgname%-hg}::hg+https://bitbucket.org/Coin3D/dime") sha256sums=('SKIP')
pkgver() { cd "$srcdir/${pkgname%-hg}" printf "r%s.%s" "$(hg identify -n)" "$(hg identify -i)" }
build() { cd "$srcdir/${pkgname%-hg}" ./configure --prefix=/usr --enable-html make }
package() { cd "$srcdir/${pkgname%-hg}" make DESTDIR="$pkgdir/" install install -D -m644 COPYING "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE" }
On 07/30/2016 11:56 AM, Alessandro Menti wrote:
Hi everyone, I've just started writing some PKGBUILDs for some programs that are not present neither in the official package repository nor in the AUR. Specifically, I've packaged libdime [1] as a required dependency for the X-Plane developer tools [2].
I'm attaching the PKGBUILD below - if someone on this list could review it, that would be much appreciated. I've also got the following questions:
- Is it correct to name the package "libdime-hg" only because its sources are checked out from a Mercurial repository (that's because no official tarballs exist any more - the Debian copyright file for the library [3] points to a now dismissed FTP site [4]), or should I just name it "libdime"?
- On the same note, assuming that naming the package "libdime-hg" is correct, does it make sense to put provides=("${pkgname%-hg}") conflicts=("${pkgname%-hg}") in the PKGBUILD? I've thought to put these two lines as "safeguards" in case I need to distinguish between a libdime VCS and non-VCS package in the future.
Cheers and thanks in advance, Alessandro Menti
*-hg/*-git/*-svn packages do not mean the source was checked out using those protocols, they mean that the package builds from the latest development sources and that therefore the PKGBUILD will automatically build e.g. the latest revision (or the latest revision of a particular development branch, depending on your scenario).
Unless you actually mean to indicate that that package fundamentally builds the development version from hg "tip", please use the version tarballs available at https://bitbucket.org/$%7Buser%7D/$%7Brepo%7D/get/$%7Brevision%7D.tar.gz
In this case, there do not appear to be tags, so just go with the latest commit hash. But still, it is false to claim that it is a development version. I don't know how you would go about calculating the actual pkgver though, if the repository doesn't seem to have tagged releases or proper versioning.
Hi Eli, thanks for the review.
Unless you actually mean to indicate that that package fundamentally builds the development version from hg "tip", please use the version tarballs available at https://bitbucket.org/$%7Buser%7D/$%7Brepo%7D/get/$%7Brevision%7D.tar.gz
In this case, there do not appear to be tags, so just go with the latest commit hash. But still, it is false to claim that it is a development version. I don't know how you would go about calculating the actual pkgver though, if the repository doesn't seem to have tagged releases or proper versioning.
That's exactly the problem - there are neither tags nor proper versioning. The only hint I've found is in the Debian copyright file [1]:
Source: hg clone https://bitbucket.org/Coin3D/dime The upstream package source tarball was generated by: hg archive -r 187 -p dime-0.20111205 ../../dime_0.20111205.orig.tar.bz2 Comment: first Debian packages by A. Maitland Bottoms bottoms@debian.org on Fri, 11 Jan 2002 14:27:21 -0500. first downloaded from ftp://ftp.sim.no/pub/snapshots/
which suggests the tarball originally released by the authors was a nightly release (incidentally, r187 corresponds to the current hg "tip").
Regarding the pkgver, I think using the ISO 8601 "reversed date" might be acceptable in this particular case.
I've attached the revised PKGBUILD below - let me know if you have any further observations.
Thanks again, Alessandro Menti
[1] http://metadata.ftp-master.debian.org/changelogs/main/d/dime/dime_0.20111205...
----- The PKGBUILD follows: -------------------------------------------- # Maintainer: Alessandro Menti <alessandro dot menti at hotmail dot it> pkgname=libdime pkgver=20111205 _commit=7cd55bc6a6d0 pkgrel=1 pkgdesc="A DXF (Data eXchange Format) file format support library" arch=('i686' 'x86_64') url="https://bitbucket.org/Coin3D/dime" license=('BSD') depends=('gcc-libs') makedepends=('doxygen' 'mercurial') source=("https://bitbucket.org/Coin3D/dime/get/$%7B_commit%7D.tar.gz") sha256sums=('23abc644771914accb47bd144ff6e533a7e6d6b6b44b588bd9ec827b236efbda')
build() { cd "$srcdir/Coin3D-dime-${_commit}" ./configure --prefix=/usr --enable-html make }
package() { cd "$srcdir/Coin3D-dime-${_commit}" make DESTDIR="$pkgdir/" install install -D -m644 COPYING "$pkgdir/usr/share/licenses/$pkgname/LICENSE" }
On 07/31/2016 02:52 AM, Alessandro Menti wrote:
Hi Eli, thanks for the review. [...] which suggests the tarball originally released by the authors was a nightly release (incidentally, r187 corresponds to the current hg "tip").
Regarding the pkgver, I think using the ISO 8601 "reversed date" might be acceptable in this particular case.
It would be, but personally I prefer revision number, so I would use "r187" myself. This tells the user how much has changed, rather than when it changed (maybe more relevant in the context of ${tag}.r${revisions}.${_commit} as output by `git describe` for things likely to get more commits, but I still like it regardless).
I've attached the revised PKGBUILD below - let me know if you have any further observations.
I do have a couple last style nits.
----- The PKGBUILD follows: -------------------------------------------- # Maintainer: Alessandro Menti <alessandro dot menti at hotmail dot it> pkgname=libdime
Most people put a line of whitespace separating the "# Maintainer:" line from the main body of the PKGBUILD. In a similar way to separating the variables from the pkgver/prepare/build/check/package functions (and the functions from each other).
pkgver=20111205
As I said above, by personal preference I would use "r187".
depends=('gcc-libs')
gcc-libs is part of the base group, and therefore all Arch Linux systems are expected to have it installed. I am not sure why there are any packages that (seemingly unnecessarily, except in the case of e.g. gcc which *needs* to depend on the same ${pkgver}-${pkgrel}) depend on it, but surely that isn't an excuse to further clutter up the pacman database with unneeded dependency chains...
source=("https://bitbucket.org/Coin3D/dime/get/$%7B_commit%7D.tar.gz")
I usually reuse the ${url} variable here if possible, but that isn't really terribly important. I think it looks nicer though, because it highlights the relationship between the homepage and the source code download location.
Hi Eli, I've fixed all the issues you found, the revised PKGBUILD is below.
depends=('gcc-libs')
gcc-libs is part of the base group, and therefore all Arch Linux systems are expected to have it installed. I am not sure why there are any packages that (seemingly unnecessarily, except in the case of e.g. gcc which *needs* to depend on the same ${pkgver}-${pkgrel}) depend on it, but surely that isn't an excuse to further clutter up the pacman database with unneeded dependency chains...
I did add it at first because, otherwise, if namcap is run on the created package, it complains about the missing dependency on gcc-libs:
libdime E: Dependency gcc-libs detected and not included (libraries ['usr/lib/libgcc_s.so.1', 'usr/lib/libstdc++.so.6'] needed in files ['usr/lib/libdime.so.1.0.0'])
Thanks again for the review, Alessandro Menti
----- The PKGBUILD follows: -------------------------------------------- # Maintainer: Alessandro Menti <alessandro dot menti at hotmail dot it>
pkgname=libdime pkgver=r187 _commit=7cd55bc6a6d0 pkgrel=1 pkgdesc="A DXF (Data eXchange Format) file format support library" arch=('i686' 'x86_64') url="https://bitbucket.org/Coin3D/dime" license=('BSD') makedepends=('doxygen' 'mercurial') source=("${url}/get/${_commit}.tar.gz") sha256sums=('23abc644771914accb47bd144ff6e533a7e6d6b6b44b588bd9ec827b236efbda')
build() { cd "$srcdir/Coin3D-dime-${_commit}" ./configure --prefix=/usr --enable-html make }
package() { cd "$srcdir/Coin3D-dime-${_commit}" make DESTDIR="$pkgdir/" install install -D -m644 COPYING "$pkgdir/usr/share/licenses/$pkgname/LICENSE" }
I forgot to remove the (now) useless build dependency on mercurial - sorry for the spam.
Cheers, Alessandro Menti
----- The PKGBUILD follows: -------------------------------------------- # Maintainer: Alessandro Menti <alessandro dot menti at hotmail dot it>
pkgname=libdime pkgver=r187 _commit=7cd55bc6a6d0 pkgrel=1 pkgdesc="A DXF (Data eXchange Format) file format support library" arch=('i686' 'x86_64') url="https://bitbucket.org/Coin3D/dime" license=('BSD') makedepends=('doxygen') source=("${url}/get/${_commit}.tar.gz") sha256sums=('23abc644771914accb47bd144ff6e533a7e6d6b6b44b588bd9ec827b236efbda')
build() { cd "$srcdir/Coin3D-dime-${_commit}" ./configure --prefix=/usr --enable-html make }
package() { cd "$srcdir/Coin3D-dime-${_commit}" make DESTDIR="$pkgdir/" install install -D -m644 COPYING "$pkgdir/usr/share/licenses/$pkgname/LICENSE" }
Den 31-07-2016 kl. 04:22 skrev Eli Schwartz via aur-general:
*-hg/*-git/*-svn packages do not mean the source was checked out using those protocols, they mean that the package builds from the latest development sources and that therefore the PKGBUILD will automatically build e.g. the latest revision (or the latest revision of a particular development branch, depending on your scenario).
Unless you actually mean to indicate that that package fundamentally builds the development version from hg "tip", please use the version tarballs available at https://bitbucket.org/$%7Buser%7D/$%7Brepo%7D/get/$%7Brevision%7D.tar.gz
In this case, there do not appear to be tags, so just go with the latest commit hash. But still, it is false to claim that it is a development version. I don't know how you would go about calculating the actual pkgver though, if the repository doesn't seem to have tagged releases or proper versioning.
https://wiki.archlinux.org/index.php/VCS_package_guidelines#Mercurial has a recommended way/example of how to go about exactly this. I don't see a reason why this version string wouldn't be okay to use/mirror for a non-"-hg" package too, if there's not otherwise a good versioning scheme in place.
This would also allow package versions to be directly comparable if a -hg package should emerge at a later point.
participants (3)
-
Alessandro Menti
-
Eli Schwartz
-
Frederik “Freso” S. Olesen