Le 11/01/2017 à 13:22, Tom Zander a écrit :
Alright, I've looked at the first one. There's a whole lot of simplification you could do, and a few actual problems.
Problems:
You need to rename the source file. It's just "v1.2.0.tar.gz" which is very generic and could conflict with other packages. This is what github creates when you push a tag, I have no choice in the matter. Why would there be a conflict? This is only used for makepkg and any package
On Saturday, 7 January 2017 14:29:58 CET Doug Newgard wrote: that is created is always compiled in its own dir. The PKGBUILD file doesn’t have a project name in front of it either, ensuring its all done in its own dir... What am I missing?
Use of $SRCDEST by some tool like pacaur, and how main repos works: all sources for all packages are stored together. So any other packages with "v1.2.0.tar.gz" source will be in conflict. To fix this, your source array should do something like that: source=(${pkgname}-${pkgver}.tar.gz::"<_srcurl>.tar.gz")
Hardcoding the version here also makes no sense when you could just use $pkgver and only have to update it in one place when you update. Hmm? I did exactlyt that. The pkver is set once and used everywhere... Maybe you looked at a ‘-git’ package?
I’ll check what Doug meant in my forthcoming review.
The install file does WAY, WAY more than it should. The only thing I see there that should be happening is creating the user and group, everything else should be removed. Maybe you are assuming that a ‘make install’ will be able to do everything we need. Unfortunately thats not the case... And I don’t want to change the upstream automake files. So individual install lines are needed.
I didn’t do my review yet, but if they are things to be done to “fix make install”, they probably should be in the package function, not the install file. I’ll come back to you later today regarding this, once I’ll had the time to review your packages (currently at work). Keep tuned, Bruno