datetime-fortran package review request

blippy · 2016-01-23 12:18:10

I found a really good package that I wanted to make available as an AUR package. It's my first attempt at creating a package, so it may not meet with the standards. Here is my PKGBUILD:

# Maintainer: Mark Carter <alt.mcarter@gmail.com>
pkgname=datetime-fortran
pkgver=1.2.0
pkgrel=1
pkgdesc="Fortran library that provides time and date manipulation facilities"
arch=('any')
url="https://github.com/milancurcic/datetime-fortran"
license=('BSD')
depends=('gcc-fortran')
source=("https://github.com/milancurcic/datetime-fortran/archive/v1.2.0.tar.gz")
md5sums=('ed7061ff5013d865543232affe74acbd')
validpgpkeys=()

prepare() {
	cd "$pkgname-$pkgver"
}

build() {
	cd "$pkgname-$pkgver"
	make
}


package() {
	cd "$pkgname-$pkgver"
	echo $pkgdir
	mkdir -p $pkgdir/usr/lib $pkgdir/usr/share/pkgconfig
	cp libdatetime.a datetime_module.mod $pkgdir/usr/lib
	cat >$pkgdir/usr/share/pkgconfig/datetime-fortran.pc <<EOF
prefix=/usr
libdir=\${prefix}/lib

Name: datetime-fortran
Description: Fortran library that provides time and date manipulation facilities
URL: https://github.com/milancurcic/datetime-fortran
Version: 1.2.0
Cflags: -I\${prefix}/lib
Libs:  -ldatetime
EOF

}

Comments?

Xyne · 2016-01-23 12:36:16

The "any" architecture is reserved for packages which, once built, can be run on any system, for example non-compiled modules for interpreted languages or data packages for games. This package will compile code that will be architecture-specific once the package is built. You should therefore use e.g. "arch=(x86_64 i686)" (assuming that both work).

Libraries should prefix the language name, not postfix it ("fortran-datetime" instead of "datetime-fortran"). If the official name of the project really is "datetime-fortran" then the package name should be "fortran-datetime-fortran", however silly that may seem. Consistency in renaming is more important than the occasional redundancy.

"gcc-fortran" should probably be in the "makedepends" array, not the "depends" (i.e. runtime dependencies) array.

Personally I prefer to use sha512sums for checksums instead of md5sums. I would recommend using at least sha1sums.

Remove the empty validpgpkeys array.

Quote all $pkgdir and $srcdir variables to avoid word expansion if the path contains a space.

Check if there is a configure script in the source that will let you install the build package with "make install" instead of doing everything manually. If there isn't, contact upstream and suggest it.

blippy · 2016-01-23 13:52:15

I have revised PKGBUILD in light of your comments:

# Maintainer: Mark Carter <alt.mcarter@gmail.com>
pkgname=fortran-datetime-fortran
pkgver=1.2.0
pkgrel=1
pkgdesc="Fortran library that provides time and date manipulation facilities"
arch=('x86_64' 'i686')
url="https://github.com/milancurcic/datetime-fortran"
license=('BSD')
makedepends=('gcc-fortran')
source=("https://github.com/milancurcic/datetime-fortran/archive/v1.2.0.tar.gz")
sha512sums=('b7699ddd59a9733f48bbf6318b20276350081d632cad39b0b533f71ca65ed01496b6c64997f458168c99c56eb6f1e3f45d0516d12171014df5cd451909419081')

prepare() {
	cd "datetime-fortran-$pkgver"
}

build() {
	cd "datetime-fortran-$pkgver"
	make
}


package() {
	cd "datetime-fortran-$pkgver"
	mkdir -p "$pkgdir"/usr/lib "$pkgdir"/usr/share/pkgconfig
	cp libdatetime.a datetime_module.mod "$pkgdir"/usr/lib
	cat >"$pkgdir"/usr/share/pkgconfig/fortran-datetime-fortran.pc <<EOF
prefix=/usr
libdir=\${prefix}/lib

Name: fortran-datetime-fortran
Description: Fortran library that provides time and date manipulation facilities
URL: https://github.com/milancurcic/datetime-fortran
Version: 1.2.0
Cflags: -I\${prefix}/lib
Libs:  -ldatetime
EOF

}

Xyne wrote:

The "any" architecture is reserved for packages which, once built, can be run on any system, for example non-compiled modules for interpreted languages or data packages for games. This package will compile code that will be architecture-specific once the package is built. You should therefore use e.g. "arch=(x86_64 i686)" (assuming that both work).

Changed as requested.

Xyne wrote:

Libraries should prefix the language name, not postfix it ("fortran-datetime" instead of "datetime-fortran"). If the official name of the project really is "datetime-fortran" then the package name should be "fortran-datetime-fortran", however silly that may seem. Consistency in renaming is more important than the occasional redundancy.

The project really is called "datetime-fortran", so I have changed the package name to "fortran-datetime-fortran".

Xyne wrote:

"gcc-fortran" should probably be in the "makedepends" array, not the "depends" (i.e. runtime dependencies) array.

Changed as requested. Note that what is compiled is specifically for Fortran, though. I can't imagine a non-Fortraner wanting to use it. It only generates a Fortran .mod file and library, no executables.

Xyne wrote:

Personally I prefer to use sha512sums for checksums instead of md5sums. I would recommend using at least sha1sums.
Remove the empty validpgpkeys array.
Quote all $pkgdir and $srcdir variables to avoid word expansion if the path contains a space.

Done

Xyne wrote:

Check if there is a configure script in the source that will let you install the build package with "make install" instead of doing everything manually. If there isn't, contact upstream and suggest it.

The package has no configure script. It does have a Makefile, but you can't "make install". I'll suggest the changes to upstream, but I'm happy going with what I've got for now.

I'm in two minds about creating fortran-datetime-fortran.pc. Upstream did not create one.

On the one hand, an absence of the pc file makes linking a pain, as any user has to hard-code the library paths if they just roll their own Makefile. It's very convenient to be able to have a Makefile containing the lines

gfortran `pkg-config --cflags fortran-datetime-fortran` foo.f90 `pkg-config --libs fortran-datetime-fortran`

As a general rule, users shouldn't have to hard-code values into their files, as assumptions about locations are easily likely to be wrong. This is particularly the case in Arch, where packages are installed to /usr. rather than a more typical /usr/local.

OTOH, upstream did not provide this affordance, so I am actually now leaning towards removing the pc file, as pkg-config won't work on any other platform anyway. It seems a general principle that packagers should not provide any "extras" outside of what upstream provides.

What's the thinking on this?

Lone_Wolf · 2016-01-23 15:08:36

freedesktop.org wrote:

pkg-config works on multiple platforms: Linux and other UNIX-like operating systems, Mac OS X and Windows. It does not require anything but a reasonably well working C compiler and a C library, but can use an installed glib if that is present. (A copy of recent glib2 is shipped together with pkg-config versions since 0.27, and this is sufficient for pkg-config to compile and work properly.)

If you setup things correctly in your package, your .pc file can be useful for others.
Upstream is also more likely to add that file if someone else already did the work.

blippy · 2016-01-23 15:56:54

Lone_Wolf wrote:

If you setup things correctly in your package, your .pc file can be useful for others.
Upstream is also more likely to add that file if someone else already did the work.

I have set up the package correctly for Arch. The problem is that upstream provides no means of installating his libraries. My PKGBUILD addresses that problem, although only for Arch.

So the question is, given what we've got - a release version 1.2.0 - should a pc file be created?

blippy · 2016-01-23 22:00:04

I am actually in discussion with the author, and we seem to favour going down either the CMake or Autotools route.

*Gulp* It will probably be me that will help with their build system.

Arch Linux

#1 2016-01-23 12:18:10

datetime-fortran package review request

#2 2016-01-23 12:36:16

Re: datetime-fortran package review request

#3 2016-01-23 13:52:15

Re: datetime-fortran package review request

#4 2016-01-23 15:08:36

Re: datetime-fortran package review request

#5 2016-01-23 15:56:54

Re: datetime-fortran package review request

#6 2016-01-23 22:00:04

Re: datetime-fortran package review request

Board footer