You are not logged in.

#1 2017-02-21 19:19:42

ampoffcom
Member
Registered: 2017-02-21
Posts: 2

PKGBUILD review request: pacaudit

Hello,

I created the package pacaudit and already uploaded it into the AUR - which wasn't the ideal workflow.

Yet, better late than never. This is my first package, so any comment and idea for improvement is highly appreciated.

Please find the package here https://aur.archlinux.org/packages/pacaudit/ and the PKGBUILD attached:

# Maintainer: Steffen Fritz <aur AT fritz DOT wtf>
pkgname=pacaudit
pkgver=0.1
pkgrel=2
pkgdesc="This package audits installed packages against known vulnerabilities. Use after pacman -Syu."
arch=('i686' 'x86_64')
url="https://github.com/steffenfritz/pacaudit"
license=('GPL3')
depends=('glibc')
makedepends=('go>=1.6')
options=('!strip')
source=("https://github.com/steffenfritz/pacaudit/archive/master.zip" "https://fritz.wtf/master.zip.asc")

build() {
    cd pacaudit-master
    go build -o pacaudit -ldflags "-s -w"
}

package() {
    mkdir -p $pkgdir/usr/bin
    cd pacaudit-master
    install -m744 $srcdir/pacaudit-master/pacaudit $pkgdir/usr/bin/pacaudit

}
validpgpkeys=('7328F6E376924E4EE266381D3D9C808E038A615C')
sha256sums=('bd6aa2105e34b602ba82a17d0ccff51e8bb65132684b4f8e3c6ab055f4a3ea01'
'78823ee5ea2b87f8f5548f44e8fec85384ab142cb69814ea653beb60cfcb24d3')

Offline

#2 2017-02-22 00:29:11

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,466

Re: PKGBUILD review request: pacaudit

Using a tarball of master if a bad idea. If you want "0.1", you need to use a tarball of "0.1".

You should quote any paths that contain variables you don't control. For example, $pkgdir and $srcdir could contain spaces.

In the package function, you're already in $srcdir/pacaudio-master, yet you include that in the install command. Why?

You can use install's "-D" option to automatically create the destination dir. No need to make it ahead of time.

Offline

#3 2017-02-22 00:46:38

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: PKGBUILD review request: pacaudit

1) Do NOT build from master! That can change without warning, instead download the versioned release, using $pkgver -- e.g. source=("$pkgname-$pkgver.tar.gz::https://github.com/steffenfritz/pacaudit/archive/$pkgver.tar.gz")
Since the github repo does not have tagged versions, you will have to ensure that a version is actually released, it seems a bit disingenuous to call it version 0.1 when it isn't actually. Since you appear to be upstream, this should be easy. smile
If for some reason you have to use a non-tagged release, GitHub allows downloading a commit using the same syntax as downloading a branch or tag.

2) The signature should likewise be versioned, and possibly uploaded to GitHub as a release artifact. wink
Since you are concerned with verifying the authenticity of your software, you might also want to consider using signed git commits/tags (git commit -S, git config --global commit.gpgsign true, git config --global tag.forcesignannotated true). Note that in the next pacman release, makepkg will support checking the signature of a git commit/tag.

3) You MUST quote "$srcdir" and "$pkgdir", as they are user-controlled variables (depending on where the PKGBUILD is downloaded to and build from) and can therefore contain any valid filename including e.g. spaces.

4) glibc is in the base group, and all installed Arch LInux systems must have it installed. It is also a dependency of numerous base-devel packages; it is required by, among others, bash, binutils, gcc-libs, coreutils, make, patch, tar, gawk, sed, file... I don't believe it should be listed as a dependency in the general case, but certainly we don't need to make things worse/uglier by making almost every single package which contains ELF binaries list it as a depends. Just take it as an article of faith that users have libc.so or else they have worse problems. wink
Similarly, there is no need for a versioned go makedepends, since Arch is already on go 1.8 and we don't support partial downgrades.

5) No need to use mkdir and then install, install -D creates the directory path you need. Also, executable binaries are traditionally installed as 755, whether they are intended to be used only by root, or not.

6) General PKGBUILD style nits: Consider moving validpgpkeys and checksums up with the other control variables, to keep things tidy. Also, you can reuse $pkgver for things like the url, reuse $url in source, etc. The pkgdesc should not be self-referencing, see Wiki: Arch packaging standards


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#4 2017-02-22 07:51:05

ampoffcom
Member
Registered: 2017-02-21
Posts: 2

Re: PKGBUILD review request: pacaudit

Thank you very much! very good points. One note to @eschwartz' point 4: namcap printed the error that it was missing. However, I will remove it.

Offline

#5 2017-02-22 13:37:36

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: PKGBUILD review request: pacaudit

Namcap is meant to offer potentially useful advice, it can sometimes catch errors the packager missed. But it's also frequently wrong, because heuristics can only get you so far. Feel free to ignore anything namcap says, if you have reason to think otherwise.

In this case, it doesn't seem to take into account the fact  that base packages should not be dependencies... possibly because the actual Devs/TUs cannot be consistent about it either. wink

In fact, the go package does not depend on glibc, despite linking against libc.so -- it doesn't have any dependencies at all, actually.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#6 2017-02-22 14:06:50

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,466

Re: PKGBUILD review request: pacaudit

ampoffcom wrote:

Thank you very much! very good points. One note to @eschwartz' point 4: namcap printed the error that it was missing. However, I will remove it.

It's completely optional. You can have the dep there or not, your call.

Offline

Board footer

Powered by FluxBB