wiringX-git PKGBUILD Review Request
All, I'm thinking of adding a wiringX-git package to AUR and wanted to put the PKGBUILD out for comment and help. It's a simple tiny package used for embedded development to manipulate GPIO pins. What I've cobbled together is: pkgname=wiringX-git _gitname=wiringX pkgver=251.54030cd pkgrel=1 pkgdesc="wiringX is a modular approach to several GPIO interfaces." url="httpx://wiringx.org/" arch=('i686' 'x86_64' 'armv6h' 'armv7h' 'aarch64') license=('MPL-2.0') makedepends=('git' 'cmake') source=('git+https://github.com/wiringX/wiringX.git') md5sums=('SKIP') pkgver() { cd "${srcdir}/$_gitname" echo $(git rev-list --count HEAD).$(git rev-parse --short HEAD) } prepare() { cd "${srcdir}/$_gitname" mkdir -p build cd build msg2 "Cmake..." cmake .. } build() { cd "${srcdir}/$_gitname/build" msg2 "Building wiringX..." make } package() { cd "${srcdir}/$_gitname/build" msg2 "Packaging wiringX..." make DESTDIR="$pkgdir/" install mv "$pkgdir/usr/local/"* "$pkgdir/usr" rm -r "$pkgdir/usr/local" install -Dm644 "${srcdir}/$_gitname/LICENSE" "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE" } And it produces: $ pacman -Qpl wiringX-git-251.54030cd-1-x86_64.pkg.tar.zst wiringX-git /usr/ wiringX-git /usr/include/ wiringX-git /usr/include/wiringx.h wiringX-git /usr/lib/ wiringX-git /usr/lib/libwiringx.so wiringX-git /usr/sbin/ wiringX-git /usr/sbin/wiringx-blink wiringX-git /usr/sbin/wiringx-interrupt wiringX-git /usr/sbin/wiringx-read wiringX-git /usr/share/ wiringX-git /usr/share/licenses/ wiringX-git /usr/share/licenses/wiringX-git/ wiringX-git /usr/share/licenses/wiringX-git/LICENSE We may also want to include the static library. Thoughts? -- David C. Rankin, J.D.,P.E.
Hmm, I know nothing on the library side of things, but as Arch conventions dictate: 1. All package titles should be lowercase, so wiringx-git, perhaps?. 2. You should probably do a provides=(libwiringx.so wiringx) so the soname is searchable and conflicts are better detected 3. According to the [wiki][1], "Do not use makepkg subroutines (e.g. error, msg, msg2, plain, warning) as they might change at any time. To print data, use printf or echo." I'm not sure if such messages are even necessary. AFAIK outputting the current step is already done by makepkg and I'm pretty sure cmake will produce its own output that make outputting "Cmake..." redundant. Otherwise, this looks like a pretty solid PKGBUILD to me! Make sure the use namcap on the PKGBUILD and the built .pkg(.tar.zst) [1]: https://wiki.archlinux.org/title/Arch_package_guidelines -- Cheers, Aᴀʀᴏɴ
In addition to what has been said, do not include the package name in the description in a self-referencing way.[1] [1] https://wiki.archlinux.org/title/Arch_package_guidelines#Package_etiquette
On 1/6/24 01:22, Jean-Claude wrote:
In addition to what has been said, do not include the package name in the description in a self-referencing way.[1]
[1] https://wiki.archlinux.org/title/Arch_package_guidelines#Package_etiquette
Thanks Aaron and Jean-Claude, I'll fix those items and put it out for a second review tomorrow (after some needed sleep!) -- David C. Rankin, J.D.,P.E.
You might also want to look at the CMake package guidelines [1]. In particular, cmake should be called from build(), not prepare(). [1] https://wiki.archlinux.org/title/CMake_package_guidelines
Hello, For libraries you can include them in the package without any issues, but something else which is common in the official repositories is splitting it into libwiringx-git and have wiringx-git depend on it. This is usually done in split packages. This is because the shared object and headers are used for linking, and pulling an entire software package within a build environment is unnecessary. This is done on a package to package basis, but take sqlite [1] for example. The main command line utility and the library is provided by the sqlite package, but the parser and analyser is split out of the main package. Its however you feel it should be structured, if you want to split it up thats up to you, but seen as the program seems pretty small in size, and the library is tiny, I doubt it would make much of a difference in this case.
We may also want to include the static library. Thoughts?
The nature of static linking is for portability, and although reading about it there is some use cases for static libraries [2], most programs which static link will compile the program from source by default. Secondly this is slightly out of the scope of Arch Linux. Unless it is Rust or Go in which static linking is used by default, almost all software I have found written in C was dynamically linked, because there is little reason not to. The one big benefit of static linking is that it is a single executable, but when you have a package manager dealing with the libraries, it becomes redundant. Plus, if everything was static linked, you would have hundreds and hundreds of duplicate references to libraries included within the executable. Also another issue is the need for recompiling to update libraries which are out of date/vulnerable, although Arch Linux already will do this in a lot of cases, if the ABI remains constant, if a dynamic library is updated, anything linked against it will continue to work. (The big if there is the ABI remaining constant :P) I am not a staff member, and thus I do not know their procedures on rebuilds, but including a static library would only be useful if you were building statically linked software, and on Arch Linux, I doubt this is the standard (couldn't find any citation for this, if someone has a link to static vs dynamic discussions from staff, please send it). Hope this helps. Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@icebound.dev [1] https://archlinux.org/packages/core/x86_64/sqlite/ [2] https://en.wikipedia.org/wiki/Static_library
Hi, According to manual.wiringx.org , wiringX is only a library and nothing else. I don't think the splitting into two packages part applies here, as there is nothing to install other than the library. -- Cheers, Aᴀʀᴏɴ
On Sat, 6 Jan 2024 15:35:23 +0000 Polarian <polarian@polarian.dev> wrote:
Hello,
For libraries you can include them in the package without any issues, but something else which is common in the official repositories is splitting it into libwiringx-git and have wiringx-git depend on it. This is usually done in split packages.
This is because the shared object and headers are used for linking, and pulling an entire software package within a build environment is unnecessary.
It's not common in the repos. It does happen, usually for a specific reason such as dependency cycles that cause issues or massive sizes (boost). The reason given here is not valid.
Hello,
According to manual.wiringx.org , wiringX is only a library and nothing else. I don't think the splitting into two packages part applies here, as there is nothing to install other than the library.
Apologies, I thought wiringx was some software + a library, I never actually checked.
It's not common in the repos. It does happen, usually for a specific reason such as dependency cycles that cause issues or massive sizes (boost). The reason given here is not valid.
I will withdraw the "common" part, but it is still valid. I gave sqlite as an example, lemon and sqlite-analyser are not that big, or is sqlite, but its still a split package. If you want to correct me, please offlist me and I will happily correct my mistake if you can justify your point. Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@icebound.dev
On 1/6/24 09:35, Polarian wrote:
The nature of static linking is for portability, and although reading about it there is some use cases for static libraries [2], most programs which static link will compile the program from source by default.
Secondly this is slightly out of the scope of Arch Linux. Unless it is Rust or Go in which static linking is used by default, almost all software I have found written in C was dynamically linked, because there is little reason not to. The one big benefit of static linking is that it is a single executable, but when you have a package manager dealing with the libraries, it becomes redundant.
Plus, if everything was static linked, you would have hundreds and hundreds of duplicate references to libraries included within the executable. Also another issue is the need for recompiling to update libraries which are out of date/vulnerable, although Arch Linux already will do this in a lot of cases, if the ABI remains constant, if a dynamic library is updated, anything linked against it will continue to work. (The big if there is the ABI remaining constant :P)
Yep, it does help! My thinking was that since this, like arm-none-eabi-gcc (and arm-none-eabi-binutils, etc..) are for cross-compiling for a different target, I was unclear whether including the static lib may be beneficial for those creating distributable packages for the target (ARM or RISC). I don't create things that are redistributable on embedded devices, more for my own use, but not sure whether there was a need otherwise. We can leave it out for now, and if somebody has a special need, they can build it and pull the static lib from the source. Take less than 60 seconds to build anyway. The reason I didn't split the package here -- is it is TINY (oh, tiny...) Having a one file package and another 3-file package (plus the LICENSE) just didn't seem like a good use of space. I'll finish going through all comments, incorporating the changes, build and then repost the PKGBUILD of another review. -- David C. Rankin, J.D.,P.E.
On 1/5/24 21:01, Aaron Liu wrote:
Hmm,
I know nothing on the library side of things, but as Arch conventions dictate:
1. All package titles should be lowercase, so wiringx-git, perhaps?. 2. You should probably do a provides=(libwiringx.so wiringx) so the soname is searchable and conflicts are better detected 3. According to the [wiki][1], "Do not use makepkg subroutines (e.g. error, msg, msg2, plain, warning) as they might change at any time. To print data, use printf or echo." I'm not sure if such messages are even necessary. AFAIK outputting the current step is already done by makepkg and I'm pretty sure cmake will produce its own output that make outputting "Cmake..." redundant.
Otherwise, this looks like a pretty solid PKGBUILD to me! Make sure the use namcap on the PKGBUILD and the built .pkg(.tar.zst)
[1]: https://wiki.archlinux.org/title/Arch_package_guidelines
I think I have all comments from all replies incorporated and it works great. The --prefix issue was solved via cmake, but the sbin issue required a quick sed of the existing CMakeLists.txt. The static lib is excluded. If there is ever an actual "Release" of wiringX, then we can remove the pkgver() function entirely. The current PKGBUID is: pkgname=wiringx-git _gitname=wiringX pkgver=251.54030cd pkgrel=1 pkgdesc="Provides a modular approach to several GPIO interfaces." url="https://wiringx.org/" arch=('i686' 'x86_64' 'armv6h' 'armv7h' 'aarch64') license=('MPL-2.0') makedepends=('git' 'cmake') provides=('libwiringx.so' 'wiringx') source=('git+https://github.com/wiringX/wiringX.git') md5sums=('SKIP') pkgver() { cd "${srcdir}/$_gitname" echo $(git rev-list --count HEAD).$(git rev-parse --short HEAD) } prepare() { cd "${srcdir}/$_gitname" sed -i '/DESTINATION sbin/s/sbin/bin/' CMakeLists.txt mkdir -p build } build() { cd "${srcdir}/$_gitname/build" cmake -DCMAKE_INSTALL_PREFIX=/usr .. make } package() { cd "${srcdir}/$_gitname/build" make DESTDIR="$pkgdir/" install install -Dm644 "${srcdir}/$_gitname/LICENSE" "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE" } The package it produces and contents are: $ pacman -Qpl wiringx-git-251.54030cd-1-x86_64.pkg.tar.zst wiringx-git /usr/ wiringx-git /usr/bin/ wiringx-git /usr/bin/wiringx-blink wiringx-git /usr/bin/wiringx-interrupt wiringx-git /usr/bin/wiringx-read wiringx-git /usr/include/ wiringx-git /usr/include/wiringx.h wiringx-git /usr/lib/ wiringx-git /usr/lib/libwiringx.so wiringx-git /usr/share/ wiringx-git /usr/share/licenses/ wiringx-git /usr/share/licenses/wiringx-git/ wiringx-git /usr/share/licenses/wiringx-git/LICENSE Let me know what else we can improve on here. The comments have all helped. If it all looks good, I'll try and put together a package for it and add it to AUR. This was prompted by my recent purchase of a milkV-duo board, a RaspberryPi Pico look-alike -- that currently runs busybox, but can actually run Arch (risc). Pretty neat little $6 computer (another $10 buys the 4-port USB/Ethernet IO board - now the little board sits on my network like a normal PI) -- David C. Rankin, J.D.,P.E.
If there is ever an actual "Release" of wiringX, then we can remove the pkgver() function entirely.
That's not how -git PKGBUILDs work. It builds from HEAD and should always build from HEAD. You really need to fix the pkgver function. Looking at the upstream CMakeLists.txt, I would version it the way they do their deb/rpm packages. set(CPACK_PACKAGE_VERSION ${PROJECT_VERSION}-${git_commits}-g${git_ver}) Adjusting for the dashes, of course, which would also include adding r before the commit count. Again, see the wiki link from earlier.
pkgver() { cd "${srcdir}/$_gitname"
Why are you using braces on one variable and not the other? It doesn't make any functional difference, but pick a style.
install -Dm644 "${srcdir}/$_gitname/LICENSE" "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
MPL-2.0 is a common license, no need to install it.
On 1/7/24 08:37, Doug Newgard wrote:
If there is ever an actual "Release" of wiringX, then we can remove the pkgver() function entirely.
That's not how -git PKGBUILDs work. It builds from HEAD and should always build from HEAD. You really need to fix the pkgver function. Looking at the upstream CMakeLists.txt, I would version it the way they do their deb/rpm packages. set(CPACK_PACKAGE_VERSION ${PROJECT_VERSION}-${git_commits}-g${git_ver}) Adjusting for the dashes, of course, which would also include adding r before the commit count. Again, see the wiki link from earlier.
Will see if I can make that work.
pkgver() { cd "${srcdir}/$_gitname"
Why are you using braces on one variable and not the other? It doesn't make any functional difference, but pick a style.
Yes, no need to brace-enclose, there are no surrounding characters that could be considered part of the variable name. The reason for it is select-buffer/middle-mouse-paste from PKGBUILDs from probably 15 years ago -- will remove
install -Dm644 "${srcdir}/$_gitname/LICENSE" "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
MPL-2.0 is a common license, no need to install it.
Great, that saves another line :) -- David C. Rankin, J.D.,P.E.
Hello, Small note, $srcdir is the current directory within the PKGBUILD functions, so you do not need to cd into $srcdir. Not a big deal, but a useful feature :) Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@icebound.dev
On 1/7/24 08:37, Doug Newgard wrote:
If there is ever an actual "Release" of wiringX, then we can remove the pkgver() function entirely. That's not how -git PKGBUILDs work. It builds from HEAD and should always build from HEAD. You really need to fix the pkgver function. Looking at the upstream CMakeLists.txt, I would version it the way they do their deb/rpm packages. set(CPACK_PACKAGE_VERSION ${PROJECT_VERSION}-${git_commits}-g${git_ver}) Adjusting for the dashes, of course, which would also include adding r before the commit count. Again, see the wiki link from earlier.
I think I've got it. There is no way to pull from the internal CPACK name to get precisely the CPACK_PACKAGE_VERSION out of it. You also cannot simply add a "TZST" generator and then either "cmake --build . --target package" or "make package" to use the zst generator as it would bypass the pacman package() altogether. You can change the format to meet your suggestion of r(commit count).g(commit) but that is about the best I was able to work out. If you know some additional cmake magic I missed that allows grabbing the name from one of the generated files in a format better than that above, you will have to help me with it, I couldn't find it. With all the changes, and removing ${srcdir} from my circa 2009 PKGBUILD go-by, the PKGBUILD is now quite tidy: pkgname=wiringx-git _gitname=wiringX pkgver=251.54030cd pkgrel=1 pkgdesc="Provides a modular approach to several GPIO interfaces." url="https://wiringx.org/" arch=('i686' 'x86_64' 'armv6h' 'armv7h' 'aarch64') license=('MPL-2.0') makedepends=('git' 'cmake') provides=('libwiringx.so' 'wiringx') source=('git+https://github.com/wiringX/wiringX.git') md5sums=('SKIP') pkgver() { cd "$_gitname" echo "r$(git rev-list --count HEAD).g$(git rev-parse --short HEAD)" } prepare() { cd "$_gitname" sed -i '/DESTINATION sbin/s/sbin/bin/' CMakeLists.txt mkdir -p build } build() { cd "$_gitname/build" cmake -DCMAKE_INSTALL_PREFIX=/usr .. make } package() { cd "$_gitname/build" make DESTDIR="$pkgdir/" install } Which produces the following: $ pacman -Qpl wiringx-git-r251.g54030cd-1-x86_64.pkg.tar.zst wiringx-git /usr/ wiringx-git /usr/bin/ wiringx-git /usr/bin/wiringx-blink wiringx-git /usr/bin/wiringx-interrupt wiringx-git /usr/bin/wiringx-read wiringx-git /usr/include/ wiringx-git /usr/include/wiringx.h wiringx-git /usr/lib/ wiringx-git /usr/lib/libwiringx.so Let me know if I need to tweak the name further -- and you may have to spoon feed me there... -- David C. Rankin, J.D.,P.E.
On Mon, 8 Jan 2024 16:56:16 -0600 "David C. Rankin" <drankinatty@gmail.com> wrote:
There is no way to pull from the internal CPACK name to get precisely the CPACK_PACKAGE_VERSION out of it. You also cannot simply add a "TZST" generator and then either "cmake --build . --target package" or "make package" to use the zst generator as it would bypass the pacman package() altogether.
You can change the format to meet your suggestion of
r(commit count).g(commit)
but that is about the best I was able to work out. If you know some additional cmake magic I missed that allows grabbing the name from one of the generated files in a format better than that above, you will have to help me with it, I couldn't find it.
I don't know of a way directly. The format you mentioned here works, as if a tag is added, you can easily switch to git describe without having to add an epoch. If you want to match upstream closer, you can do it by parsing CMakeLists.txt directly, something like awk 'match($0,/set\(PROJECT_VERSION ([0-9.]*)/,a) {print a[1];}' CMakeLists.txt to get you the project version, then add the rest.
On 1/8/24 17:52, Doug Newgard wrote:
r(commit count).g(commit)
but that is about the best I was able to work out. If you know some additional cmake magic I missed that allows grabbing the name from one of the generated files in a format better than that above, you will have to help me with it, I couldn't find it. I don't know of a way directly. The format you mentioned here works, as if a tag is added, you can easily switch to git describe without having to add an epoch. If you want to match upstream closer, you can do it by parsing CMakeLists.txt directly, something like awk 'match($0,/set\(PROJECT_VERSION ([0-9.]*)/,a) {print a[1];}' CMakeLists.txt to get you the project version, then add the rest.
That works fine to pick out the "2.0" Project Version. Where were you thinking that would be proper in the filename? As a prefix to the current pkgver? The wiki page is silent on considering both. It's clear the version "should be the same as the version released by the author", but how would you incorporate both the CMakeList info any the git repository info? Something like: wiringx-git-2.0.r251.g54030cd-1-x86_64.pkg.tar.zst I'm good either way, though adding the 2.0 does make the name seem rather long. What do you think? -- David C. Rankin, J.D.,P.E.
In addition to things others have said.
url="httpx://wiringx.org/"
Typo
pkgver() { cd "${srcdir}/$_gitname" echo $(git rev-list --count HEAD).$(git rev-parse --short HEAD) }
This will cause problems if there is ever a release. See https://wiki.archlinux.org/title/VCS_package_guidelines#Git
mv "$pkgdir/usr/local/"* "$pkgdir/usr" rm -r "$pkgdir/usr/local"
Can you not set a prefix? This step should not normally necessary.
$ pacman -Qpl wiringX-git-251.54030cd-1-x86_64.pkg.tar.zst ... wiringX-git /usr/sbin/ wiringX-git /usr/sbin/wiringx-blink wiringX-git /usr/sbin/wiringx-interrupt wiringX-git /usr/sbin/wiringx-read
You cannot install things to /usr/sbin/. This package isn't even installable as-is, pacman will error out.
We may also want to include the static library. Thoughts?
Why?
On 1/6/24 11:36, Doug Newgard wrote:
url="httpx://wiringx.org/" Typo
fat-fingers
pkgver() { cd "${srcdir}/$_gitname" echo $(git rev-list --count HEAD).$(git rev-parse --short HEAD) } This will cause problems if there is ever a release. See https://wiki.archlinux.org/title/VCS_package_guidelines#Git
If there is ever a release -- then I propose removal. Given no release and 61 forks -- looks unlikely it is moving toward a release.
mv "$pkgdir/usr/local/"* "$pkgdir/usr" rm -r "$pkgdir/usr/local"
Can you not set a prefix? This step should not normally necessary.
No, unfortunately this is a limitation on how the CMakeLists.txt file was written and how the --prefix option to cmake is ignored unless it is specially provided for or one of the --package modes is called (deb or rpm, but no Arch)
$ pacman -Qpl wiringX-git-251.54030cd-1-x86_64.pkg.tar.zst ... wiringX-git/usr/sbin/ wiringX-git /usr/sbin/wiringx-blink wiringX-git /usr/sbin/wiringx-interrupt wiringX-git /usr/sbin/wiringx-read You cannot install things to/usr/sbin/. This package isn't even installable as-is, pacman will error out.
I'll have to just sed this in prepare(). Good catch!
We may also want to include the static library. Thoughts? Why?
Addressed in response to polarian's comments. We will just leave it out and let anybody with a special need suffer through the 60 second build :) -- David C. Rankin, J.D.,P.E.
On 1/6/24 11:36, Doug Newgard wrote:
mv "$pkgdir/usr/local/"* "$pkgdir/usr" rm -r "$pkgdir/usr/local"
Can you not set a prefix? This step should not normally necessary.
Yes it can, I was reading the cmake documentation wrong: build() { cd "${srcdir}/$_gitname/build" cmake -DCMAKE_INSTALL_PREFIX=/usr .. make } That takes care of the /usr issue -- now the sbin issue is all that remains. -- David C. Rankin, J.D.,P.E.
participants (6)
-
Aaron Liu
-
David C. Rankin
-
Doug Newgard
-
Jakub Klinkovský
-
Jean-Claude
-
Polarian