Vanilla BOINC packages: the reason and the purpose

I have very controversial feelings about open-source software and Linux OS. From one hand, I like the idea of the transparency, when you can always check what is really doing every application you run. From the other hand, as a maintainer of the application, you lose some part of control on it, because it is possible to modify some application's behavior (e.g. via distro patches), that contradicts the original idea of it or break some functionality. And because there are so many different OSs, you can't keep an eye on all of them. That is why sometimes you receive a bug report that looks completely weird, and when you start doing the investigation, you realize, that this happened because of the distro patch, that was intended to fix another issue, but as a result introduced a new one. And, as a maintainer of the application, there are not so much options for you here. But in any case, you have unsatisfied user, that is always bad.

We, at BOINC, faced several times the situation when the package that is distributed with the distro is completely broken, and users have no idea how to fix that. You can post instructions, blog posts, answer questions of forums, but still the same question about the same bug will be asked. Sometimes the communication with the distro maintainers becomes hot, and every party is completely sure that only their opinion is correct.

To get rid of this situation, we decided to create our own BOINC vanilla builds for Linux. We have started with the most popular distributions: Debian, Ubuntu, Fedora and openSUSE. Currently we target only the LTS releases that are officially supported, so that is why for now we provide packages for Ubuntu 20.04 and 22.04 only.

More details (including the list of supported OSs) are here: https://github.com/BOINC/boinc/wiki/Linux-DEB-and-RPM-support

Since building all these packages (20 in total for every version) is quite a task, I had to try to automate this as much as possible, including adding some integration tests to avoid very dumb bugs. I can't say that the current CI is finished, but it does its work already: every night we have a new build that is automatically published to the 'nightly' channel on the BOINC official website. This gives our users the opportunity to test new features as soon as they added to the codebase even before the alpha testing phase begins. I can't say this is a recommended way of installing BOINC, but since we have now 2-3 releases every year, it might be helpful for those who have problems with the issues that are blockers for them only.

These packages are not yet recommended to use, but the first result is already very promising. On the video below the process of installation of both BOINC client and Manager on Ubuntu 22.04 is shown:

Of course, there are still some issues, but now it will be much easier to fix them and deliver to our users faster.

Stay tuned for further updates.