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.

gosh, cannot wait for this to land in extra.

Please keep comments restricted to packaging issues and report bugs on the repository.

It still does not recognize the LEDs on the Nvidia video card or the LEDs on the Cosair RAM memory

1) to reduce build times and 2) allow independent installation of the daemon which will officially only optionally depend on the other two packages as of v2.0. AFAICT, split packages serve neither of these purposes, please correct me if I'm wrong.

For the first point, it will reduce build time only for the people that don't want the full program, otherwise it would slightly increase it. As for the second, instead of makepkg -Ccfi, using simply makepkg -Ccf and selectively installing with makepkg -U achieves the same result as splitting it into multiple PKGBUILDs. Most AUR helpers can also do it this way if instructed to install only one package from a single split PGKBUILD. That being said, the a split PKGBUILD will take longer to build indeed.

Isn't it possible to clear an existing chroot and build another package in it? I am not familiar with paru.

The way makepkg chroots work, is that there is a "pristine" chroot, which serves as a base system with only base-devel installed normally. This is also referred to as the root chroot in the wiki. When makechrootpkg is invoked, the root chroot is cloned into a working chroot and the working chroot gets updated and the PKGBUILDs dependencies are installed into it. In in the case of multiple PKGBUILDs, this process of copying, updating and installing dependency packages in the working chroot, happens for each PKGBUILD individually.

This is also a little self-serving from my part, as I build packages in Arch linux docker containers through GH Actions, a single split PKGBUILD would require only a single instance instead multiple.

Hi @loathingkernel,

As @codifryed mentioned, two primary reasons we separated our packages is 1) to reduce build times and 2) allow independent installation of the daemon which will officially only optionally depend on the other two packages as of v2.0. AFAICT, split packages serve neither of these purposes, please correct me if I'm wrong.

It wouldn't require to download the same source three times, although if this is important for the user it can be worked around using pacman facilities such as SRCDEST.

Yes, this is less than ideal but I don't see it as a deal breaker either. The source isn't huge.

The suggested way of building packages from the AUR is in clean chroots. Building three separate packages for a user that wants all three would require setting up and updating tree separate instances of clean chroots, which is a time-consuming process during building. paru for example supports building in clean chroots if configured that way.

Isn't it possible to clear an existing chroot and build another package in it? I am not familiar with paru.

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

I am also only seeing building in a clean chroot suggested when debugging in the context of installing AUR packages.

https://wiki.archlinux.org/title/Arch_User_Repository#Debugging_the_package_build_process

It should ensure that all three packages are updated in lock-step, without the potential of mixing different versions of them because one of them was left behind.

We considered this scenario. However, decided that a user doing officially unsupported partial upgrades is doing that at their own risk.

Furthermore, my personal opinion is that if this package was eventually to be picked up for packaging in Arch's repos, my experience suggests that it would be combined into a single split package, although that's not something that I can be certain of happening. Making it a split package now would certainly make it easier if it was to happen.

I am open to packaging the application idiomatically but am not convinced split packages serve our purpose. On a binary release, it's less of a hassle for the user as they aren't building anything. But it'd still force them to install all packages.

@codifryed first of all, thank you for looking into this. I should mention that indeed this might be a little inconvenient from the perspective of a user, but from the perspective of a packager it would be more convenient.

The benefits of a split package, in no particular order of importance.

• It wouldn't require to download the same source three times, although if this is important for the user it can be worked around using pacman facilities such as SRCDEST.
• The suggested way of building packages from the AUR is in clean chroots. Building three separate packages for a user that wants all three would require setting up and updating tree separate instances of clean chroots, which is a time-consuming process during building. paru for example supports building in clean chroots if configured that way.
• It should ensure that all three packages are updated in lock-step, without the potential of mixing different versions of them because one of them was left behind.

Furthermore, my personal opinion is that if this package was eventually to be picked up for packaging in Arch's repos, my experience suggests that it would be combined into a single split package, although that's not something that I can be certain of happening. Making it a split package now would certainly make it easier if it was to happen.

Hi @loathingkernel,

Thanks for the examples. In those pkgbuilds I see a single build step for all sub-packages. We have no common build process, as all 3 are essentially independent and it appears that a split-package would require building all 3 even if a user wanted to only install 1 of the sub packages.

What benefits do you see to the spit-package over 3 separate packages for coolercontrol?
We might have missed something, but when we researched and analyzed the differences, 3 separate packages seemed to fit the best, especially as in the future coolercontrol-liqctld will be optional and the desktop app is pretty much already optional. The build time for the desktop app alone for example is significant.

@codifryed the different build procedures is usually handled by building the package in multiple steps in different subfolders if required (due to source conflicts for example), i.e

• ppsspp, two builds into two different directories and dependencies per package inside the package_() function
• glibc
• mesa, which splits a single build step into multiple packages

From reviewing the whole set of PKGBUILDs I don't see anything that wouldn't fit in the split package paradigm.

As I understand it @loathingkernel, the split package does not fit our use case.

The repo is the same for the difference packages, but they have very different build processes and require different build functions. Also the dependencies between them will be relaxed in an upcoming release.

Why was this package split into three separate pkgbuilds instead of making it a split package?