4 ms·

As a user of Linux, I wish Linux distributions would abandon their build systems which really only work well for C and maybe C++, and also only work on one plat

As a user of Linux, I wish Linux distributions would abandon their build systems which really only work well for C and maybe C++, and also only work on one platform (not even the whole of linux!) meaning that packaging has to be duplicated for every OS, and stuck to using more familiar language-specific build systems that work everywhere. (this rant more or less equally applies to all os-or-distro-specific build systems) --- This rant is only semi-serious. I do see some value in the Linux distribution style packaging. In particular, I do sympathise with the need to do cross-language builds. But goodness are they a pain to work with, and probably the biggest barrier to me shipping software on Linux. My hope is that eventually an evolution on build systems like bazel/buck2 will lead to a truly universal build system that is both cross-platform and cross-language. But unfortunately it doesn't look like it's coming soon.

Hasnep 2y ago
If you only care about Linux and MacOS then Nix can be that universal cross language build tool.
mananaysiempre 2y ago
> [Distro-specific build systems are] probably the biggest barrier to me shipping software on Linux. Don’t[1]. Ship source tarballs (or VCS tags). I’ll grant that most distros’ build systems are antiquated and, in places, silly. (That includes Nixpkgs, first released 2006.) We could really use some fresh ideas there. But they’re also not for you (or me) in your (or my) capacity as a software author. They’re there for a person who works on packaging software for, most of the time, a single distro, and their balance of complexity and flexibility is calibrated accordingly. One of the functions of that person is also to keep you honest and represent the interests of users before you, because they have more expertise than the users but not as much of an attachment to your software as you. The ecosystem is less healthy when the author tries to fill in for the packager. “But then the users will come to my bugtracker to complain about bugs in patched versions!” Pre-Google, we used to have a solution for that: a configure option to set the bug reporting email, present in all GNU software. Nowadays it’s not clear what a good solution could be, but it does seem like, unfortunately, the author will have to maintain a table of packager contact information for the end users. [1] https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html https://drewdevault.com/2021/09/27/Let-distros-do-their-job....
- rat87 2y ago
  That doesn't scale though beyond the most popular open source apps especially those in c/c++ Less popular apps or closed source apps don't work. Things with old dependencies won't work. Other language with package manager which depend on dependencies and dependency versions that may not be in distro packages may have trouble. For the core the distro model might work. For the rest maybe something like flatpack from the devs might scale
- pimeys 2y ago
  This is why I'm really looking into SerpentOS and their moss build system. Kind of like a combination of Nix and AUR. Simple syntax, simple to create packages, atomic. https://serpentos.com/docs/packaging/ https://serpentos.com/docs/packaging/

Hasnep 2y ago

If you only care about Linux and MacOS then Nix can be that universal cross language build tool.

mananaysiempre 2y ago

> [Distro-specific build systems are] probably the biggest barrier to me shipping software on Linux. Don’t[1]. Ship source tarballs (or VCS tags). I’ll grant that most distros’ build systems are antiquated and, in places, silly. (That includes Nixpkgs, first released 2006.) We could really use some fresh ideas there. But they’re also not for you (or me) in your (or my) capacity as a software author. They’re there for a person who works on packaging software for, most of the time, a single distro, and their balance of complexity and flexibility is calibrated accordingly. One of the functions of that person is also to keep you honest and represent the interests of users before you, because they have more expertise than the users but not as much of an attachment to your software as you. The ecosystem is less healthy when the author tries to fill in for the packager. “But then the users will come to my bugtracker to complain about bugs in patched versions!” Pre-Google, we used to have a solution for that: a configure option to set the bug reporting email, present in all GNU software. Nowadays it’s not clear what a good solution could be, but it does seem like, unfortunately, the author will have to maintain a table of packager contact information for the end users. [1] https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html https://drewdevault.com/2021/09/27/Let-distros-do-their-job....

rat87 2y ago
That doesn't scale though beyond the most popular open source apps especially those in c/c++ Less popular apps or closed source apps don't work. Things with old dependencies won't work. Other language with package manager which depend on dependencies and dependency versions that may not be in distro packages may have trouble. For the core the distro model might work. For the rest maybe something like flatpack from the devs might scale
pimeys 2y ago
This is why I'm really looking into SerpentOS and their moss build system. Kind of like a combination of Nix and AUR. Simple syntax, simple to create packages, atomic. https://serpentos.com/docs/packaging/ https://serpentos.com/docs/packaging/