Arch Linux User Repository

With the release of 1.4.1 CoolerControl has now been spit up into several packages. This requires users to uninstall and then reinstall the application.

See: https://gitlab.com/coolercontrol/coolercontrol/-/issues/347

There's an upside, there's now a binary AUR package coolercontrol-bin for less compile time!

Post-installation steps:

sudo systemctl enable --now coolercontrold

Then open the desktop application.

Cleaned up the make deps a bit and tested in a chroot.

I think that you should not add base-devel and maybe some other packages to makedepends

If people is installing coolercontrol with some AUR helper with the option to remove makedepends packages, also archlinux-keyring, appmenu-gtk-module (for Plasma) will be removed.

Ok, I can see that and makes good sense what you're saying, especially for official packages, which is perhaps what you're getting at.

I guess it's a bit confusing as the different docs and pkgbuilds are not very clear, at least to me. (i.e. The nodejs packaging guidelines suggest using nvm, and the package has no runtime node dependency similar to other aur pkgbuilds that also use nvm)

All good, learning never stops, changes pushed.

@codifryed: In that case, just use nodejs>=18 as a dependency, since both nodejs-lts-hydrogen and nodejs-lts-iron provide nodejs as well.

As a general rule, my advice would be to not design a PKGBUILD for building inside a user's regular desktop system, because that's the wrong way to build packages anyway. Packages built that way will often incur unwanted dependencies simply because ./configure scripts will often automatically enable features if they recognize that the dependencies needed for that specific feature is installed/available at compile time (and those unwanted depdencies won't even be listed in the package's metadata, thus making it even more error-prone to re-use the built package on other machines than the one on which it was compiled). The proper way to build a package from a PKGBUILD is to use a clean chroot, and there's a dedicated script to do just that:

https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot

Also, needlessly using AUR packages as build-time dependencies makes it a lot more difficult to build the package using the "clean chroot" method, because with the nvm dependency, the user would need to setup their own package repo on a webserver, create their own config file in /usr/share/devtools/pacman.conf.d/ and their own corresponding symlink to /usr/bin/archbuild (comparable to symlinks like /usr/bin/extra-x86_64-build or /usr/bin/multilib-build).

Thank you both. @hardfalcon @thes1lv3r

One concern that arose when testing this is with the nodejs-lts replacement of nvm, is that it then forces users to downgrade their installed version of nodejs, if it's there, which seems pretty sub-optimal. Originally I used the nvm way, not only because I saw other apps taking advantage of it, but also to help produce consistent builds separate from what nodejs package the user had installed.

That being said, I doesn't Have to be 18.x.x and it will install fine with the latest nodejs at 21.x.x, aka by just having npm as a dependency. It just can't be less than 18.x.x. to build properly.

@codifryed: Oh sorry, I wasn't aware you were actually using those files. In that case, just keeping them should be okay (though I'd still recommend removing the executable bit on both PKGBUILDs since it's not needed). Tbh, I don't know if it is possible to add a custom branch, or what implications/side effects that might have, because I've never tried that.

@thes1lv3r: You're right, for the AUR package, this should be 3 and not 2.1. I routinely use major.minor format pkgrel numbers in my private repo when I modify/update existing packages for release engineering purposed, because this makes it easier to switch back to "official" Archlinux packages when I remove packages again from my repo (for example because the desired changes have been adopted by the respective Archlinux package maintainer). I had simply forgotten to change the 2.1 to 3 before creating the diff that I posted here.

The release number. This is usually a positive integer number that allows to differentiate between consecutive builds of the same version of a package. As fixes and additional features are added to the PKGBUILD that influence the resulting package, the pkgrel should be incremented by 1. When a new version of the software is released, this value must be reset to 1. In exceptional cases other formats can be found in use, such as major.minor.

PKGBUILD#pkgrel

@hardfalcon Would it be more correct to use pkgrel=3 here, instead of pkgrel=2.1?

Thanks @hardfalcon !

I'll patch it up. The makefile and test-pkgbuild are very helpful for me for pre-release testing. Do you think it's ok if I move them to test branch in the repo?

I've reworked the PKGBUILD:

1. added python-setuptools to the makedepends array to make the PKGBUILD work in a clean chroot,
2. replaced the makedepends on the nvm AUR package with the nodejs-lts-hydrogen package from the official Archlinux repos,
3. sorted all dependencies alphabetically,
4. The PKGBUILD shouldn't have the executable bit set, so it should get a chmod 644. Also, the files Makefile and TEST-PKGBUILD are not needed and can be removed.

Here's the diff/patch:

diff --git a/PKGBUILD b/PKGBUILD
old mode 100755
new mode 100644
index 0aae3fb14065..8fa23a5f593a
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -3,44 +3,45 @@
 pkgname=coolercontrol
 _app_id="org.$pkgname.CoolerControl"
 pkgver=1.0.0
-pkgrel=2
+pkgrel=2.1
 pkgdesc="A program to monitor and control your cooling devices"
 arch=('x86_64')
 url="https://gitlab.com/coolercontrol/coolercontrol"
 license=('GPL3')
 depends=(
+  'gcc-libs'
+  'glibc'
+  'gtk3'
   'hicolor-icon-theme'
-  'python'
+  'libappindicator-gtk3'
   'liquidctl'
+  'python'
   'python-setproctitle'
   'python-fastapi'
-  'uvicorn'
-  'gcc-libs'
-  'glibc'
   'python-pydantic'
   'python-urllib3'
+  'uvicorn'
   'webkit2gtk'
-  'gtk3'
-  'libappindicator-gtk3'
 )
 makedepends=(
-  'python-build'
-  'python-wheel'
-  'python-installer'
-  'cargo'
-  'npm'
-  'nvm'
-  'webkit2gtk'
+  'appmenu-gtk-module'
   'base-devel'
+  'cargo'
   'curl'
-  'wget'
   'file'
-  'openssl'
-  'appmenu-gtk-module'
   'gtk3'
   'libappindicator-gtk3'
   'librsvg'
   'libvips'
+  'nodejs-lts-hydrogen'
+  'npm'
+  'openssl'
+  'python-build'
+  'python-installer'
+  'python-setuptools'
+  'python-wheel'
+  'webkit2gtk'
+  'wget'
 )
 checkdepends=(
   'appstream-glib'
@@ -66,29 +67,11 @@ sha256sums=(
   '3377dbd54f7d506a95e53d6d0aa323af94191067479d2eca5b45d34065a1c265'
 )

-_ensure_local_nvm() {
-  # let's be sure we are starting clean
-  which nvm >/dev/null 2>&1 && nvm deactivate && nvm unload
-
-  export NVM_DIR="${srcdir}/$pkgname-$pkgver/coolercontrol-ui/.nvm"
-  # The init script returns 3 if version specified
-  # in ./.nvrc is not (yet) installed in $NVM_DIR
-  # but nvm itself still gets loaded ok
-  source /usr/share/nvm/init-nvm.sh || [[ $? != 1 ]]
-}
-
-prepare() {
-  _ensure_local_nvm
-  cd "${srcdir}/$pkgname-$pkgver/coolercontrol-ui"
-  nvm install 18.18.2
-}
-
 build() {
   cd "${srcdir}/$pkgname-$pkgver/coolercontrol-liqctld"
   python -m build --wheel --no-isolation
   # This is the new UI in preview. The above Python coolercontrol-gui package will be removed with the next release
   cd "${srcdir}/$pkgname-$pkgver/coolercontrol-ui"
-  _ensure_local_nvm
   npm ci
   npm run build
   cp -r dist/* "${srcdir}/$pkgname-$pkgver/coolercontrold/resources/app/"