Re: [aur-general] PKGBUILD review request: libdime-hg
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/${user}/${repo}/get/${revision}.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.
--
Namasté,
Frederik “Freso” S. Olesen
Re: [aur-general] PKGBUILD review request: libdime-hg
I forgot to remove the (now) useless build dependency on mercurial -
sorry for the spam.
Cheers,
Alessandro Menti
- The PKGBUILD follows:
# Maintainer: Alessandro Menti
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"
}
Re: [aur-general] PKGBUILD review request: libdime-hg
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
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"
}
Re: [aur-general] PKGBUILD review request: libdime-hg
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
> 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/${_commit}.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.
--
Eli Schwartz
Re: [aur-general] PKGBUILD review request: libdime-hg
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/${user}/${repo}/get/${revision}.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 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-2_copyright
- The PKGBUILD follows:
# Maintainer: Alessandro Menti
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/${_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"
}
Re: [aur-general] PKGBUILD review request: libdime-hg
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:
> 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
*-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/${user}/${repo}/get/${revision}.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.
--
Eli Schwartz
[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-2_copyright
[4] ftp://ftp.sim.no/pub/snapshots/
- The PKGBUILD follows:
# Maintainer: Alessandro Menti
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"
}
