logo

drewdevault.com

[mirror] blog and personal website of Drew DeVault git clone https://hacktivis.me/git/mirror/drewdevault.com.git

Let-distros-do-their-job.md (6179B)


  1. ---
  2. title: "Developers: Let distros do their job"
  3. date: 2021-09-27
  4. ---
  5. I wrote a post some time ago titled [Developers shouldn't distribute their own
  6. software][0], and after a discussion on the sr.ht IRC channel today, the topic
  7. seems worthy of renewed mention. Let's start with this: what exactly is a
  8. software distribution, anyway?
  9. [0]: https://drewdevault.com/2019/12/09/Developers-shouldnt-distribute.html
  10. I use "software distribution" here, rather than "Linux distribution", because it
  11. generalizes better. For example, all of the major BSD systems, plus Illumos and
  12. others besides, are software distributions, but don't involve Linux. Some differ
  13. further still, sitting on top of another operating system, such as Nix or
  14. pkgsrc. What these systems all have in common is that they concern themselves
  15. with the *distribution* of *software*, and thus are a *software distribution*.
  16. An important trait of these systems is that they function independently of the
  17. development of the software they distribute, and are overseen by a third party.
  18. For the purpose of this discussion, I will rule out package repositories which
  19. are not curated by the third-party in question, such as npm or PyPI. It is no
  20. coincidence that such repositories often end up [distributing][1] [malware][2].
  21. [1]: https://www.zdnet.com/article/two-malicious-python-libraries-removed-from-pypi/
  22. [2]: https://www.trendmicro.com/vinfo/dk/security/news/cybercrime-and-digital-threats/hacker-infects-node-js-package-to-steal-from-bitcoin-wallets
  23. Software distributions are often volunteer-run and represent the interests
  24. of the users; in a sense they are a kind of [union][3] of users. They handle
  25. building your software for their system, and come to the table with
  26. domain-specific knowledge about the concerns of the platform that they're
  27. working with. There are hundreds of Linux distros and each does things
  28. differently — the package maintainers are the experts who save you the
  29. burden of learning how all of them work. Instead of cramming all of your files
  30. into /opt, they will carefully sort it into the right place, make sure all of
  31. your dependencies are sorted upon installation, and make the installation of
  32. your software a single command (or click) away.
  33. [3]: https://en.wikipedia.org/wiki/Trade_union
  34. They also serve an important role as the user's advocate. If an update ships
  35. which breaks a bunch of other packages, they'll be in the trenches dealing with
  36. it so that the users don't face the breakage themselves. They are also the first
  37. line of defense preventing the installation of malware on the user's system.
  38. Many sideloaded packages for Linux include ~~telemetry~~ spyware or adware from
  39. the upstream distributor, which is usually patched out by the distribution.
  40. Distributions are also working on innovative projects at the scale of the entire
  41. software ecosystem, and are dealing with bigger picture things than you need to
  42. concern yourself with. Here are some things which they have already solved:
  43. - Automatic updates and dependency management
  44. - Universal cryptographic signatures for all packages
  45. - Worldwide distribution and bandwidth sharing via mirrors
  46. - System-wide audits of software installed on your machine
  47. - CVE management and patch distribution
  48. - Long-term support
  49. There are several areas of open research, too, such as reproducible builds or
  50. deterministic whole-system configuration like Nix and Guix are working on. You
  51. can take advantage of all of this innovation and research for the low price of
  52. zero dollars by standing back and letting distros handle the distribution of
  53. your software. It's what they're good at.
  54. There are a few things you *can* do to make this work better.
  55. - Ship your software as a simple tarball. Don't ship pre-built binaries and
  56. definitely don't ship a "curl | bash" command. Naive users will mess up their
  57. systems when they use them.
  58. - Use widely adopted, standard build systems and methodologies. Use the standard
  59. approach for your programming language. They have already been through the
  60. gamut of distros and their operating modes are well-understood by packagers.
  61. - [Ship good release notes][4]. Distro packagers read them! Give them a head's
  62. up about any important changes which might affect their distro.
  63. - Be picky with your dependencies and try to avoid making huge dependency trees.
  64. Bonus: this leads to better security and maintainability!
  65. - Maintain a friendly dialogue with distro maintainers if and when they come
  66. asking questions. They're the expert on their distro, but you're the expert on
  67. your software, and sometimes you will meet to compare notes.
  68. *See also: [FOSDEM 2018 - How To Make Package Managers Cry](https://archive.fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/)*
  69. [4]: https://drewdevault.com/2021/05/19/How-to-write-release-notes.html
  70. One thing you shouldn't do is go around asking distros to add your program to
  71. their repos. Once you ship your tarballs, your job is done. It's the *users* who
  72. will go to their distro and ask for a new package. And users — do this! If
  73. you find yourself wanting to use some cool software which isn't in your distro,
  74. go ask for it, or better yet, package it up yourself. For many packages, this is
  75. as simple as copying and pasting a similar package (let's hope they followed my
  76. advice about using an industry-standard build system), making some tweaks, and
  77. building it.
  78. Distros are quite accessible projects, packaging is usually not that difficult.
  79. Distributions always need more volunteers, and there are plenty of friendly
  80. experts at your local distro who would be pleased to help you figure out the
  81. finer details, assuming you're prepared to stand up and do the work yourself.
  82. Once you get used to it, making and submitting a new package can take as little
  83. as 10 or 15 minutes for a simple one.
  84. Oh, and if you are in the developer role — you are presumably also a user
  85. of both your own software and some kind of software distribution. This puts you
  86. in a really good position to champion it for inclusion in your own distro :)
  87. ---
  88. P.S. Systems which invert this model, e.g. Flatpak, are completely missing the
  89. point.