In the current live version of Pacstall, the PacScript specification allows for various types of dependencies (runtime, build, optional). This strategy works well for packages published within the same distribution, such as Ubuntu 23.04. However, it has been proven multiple times that it doesn't work effectively when dealing with multiple distributions that package different versions of base packages (e.g., openssl, nodejs, go).
Let's consider a hypothetical PacScript example: Imagine a person wants to distribute their new GUI application written in Go. They discover Pacstall and decide it's the best way to distribute packages on Debian-based distributions. After quickly learning the syntax for the PacScript file, they fill in the name, description, download link, and a single dependency: Go (the programming language). They test it locally using the Pacstall Org. tooling, and it works perfectly. Satisfied, they publish it to the Pacstall main software repository. However, over time, they discover that while the app works for some users, it fails for many others. This outcome confuses the author. How could it work on their system but not on others?
The problem lies in the lack of consideration for dependency versions. The author is running the current Ubuntu LTS, which includes go version 1.18. This version introduces many new APIs to the language, which are incompatible with earlier versions. However, Pacstall users who reported errors were using Debian 11, PopOS!, and other distributions that are not as up-to-date as Ubuntu. Most of these distributions ship go 1.17 or even older versions.
The solution is simple: introduce version control.
The proposed approach (pacstall/libpacstall#105)
The currently proposed approach is to add optional version checks for dependencies. While this is a step in the right direction, it does not completely solve the problem. Why? Because since it's optional, and considering our desire for compatibility with Arch's PKGBUILD specification, most people will choose not to use it.
You are correct. PKGBUILD works very well for Arch, but it won't work as effectively for us for the same reason. Arch is a rolling release distribution, which means that everyone is (eventually) running the same versions of software. They don't have to specify versions because there are no other versions than what is currently in the official repositories. On the other hand, Debian-based distributions are mostly fixed releases. Users of these distributions are not running the same versions of the same software, and they probably shouldn't be. Since we don't have the same luxury as Arch, we need mandatory version checks. This ensures a properly functioning package manager that doesn't break systems.
In my opinion, the incompatible property is just a workaround that hides the larger problem. Let's continue the story of the author from earlier:
The author noticed that their users were using different distributions, so they came up with a plan. They placed all the failing distributions in the incompatible property of the PacScript, which would generate an error message immediately, preventing users from encountering strange build system errors. Everything seemed fine at first, but a Debian user reached out to the author explaining that although they noticed the published application required Go 1.18, they found a solution. The user installed Go 1.18 from Debian 12's backports, but the application still wouldn't install. Why? Because even though the user had all the correct dependencies installed, the author had blacklisted their distribution. In theory, this doesn't make any sense.
Make all dependency version properties in the PacScript specification mandatory.
Yes, it does. Rolling release distributions and fixed release distributions have different advantages and disadvantages. Versioning is a necessity for fixed releases.