Orbifx's Logarion 🌙
Title:
Distributing software
Authors:
orbifx
Date:
Topics:
Technology > Programming
Keywords:
package managers, packages, programming
Id:
59b11fdb-30fe-49eb-9735-654b897113e3

How should one distribute the software they have written? There are two targets groups I consider, the general public and coders, but there is a grey line too.

For general public applications & runtime libraries:

Linux: 1. Create statically build executables for all others, or use AppImage <https://appimage.org> 2. Package it for your favourite distribution's package manager 3. Hope that package maintainers of other distributions take on packaging your application

macOS: 1. Apple Disk Image, for those without Homebrew. 2. Homebrew <https://brew.sh> (package manager)

Windows: 1. Statically linked executable, for those that don't have MSYS2 2. MSYS2 <https://www.msys2.org> (package manager)

For source libraries, not runtime libraries, if your language has a package manager release there. Otherwise, release for your favourite Linux package manager, Windows MSYS2 or macOS Homebrew.

Rationale for public

As developers, we have a duty for the hardware requirements we push on to users. Please aim to support hardware that came to the markets 8 or more years ago. This can stop the waste of still useful electronic devices.

The aim is to spare the general public resources: CPU, memory, network bandwidth and most importantly, hassle! Having a package for popular package managers means your distributable can share dependencies with other applications installed on the target machine, thus saving disk space and network quota when updating.

But you won't get your package in every package manager, unless it's extremely popular, so build an executable for more obscure distros. Hopefully your application is written in a light language that doesn't bring with it big dependencies (>100 MiB, docker, electron, et al).

Rationale for coders

It is reasonable to expect developers to have more or less a similar environment to yours. This is normally and best facilitated by the language's package manager, which can fullfill library dependencies in a platform agnostic way (unlike distro package managers). At the time this is written, I have no expectations that every distribution's package managers are ever going to catch up with all the libraries for every language. Like others, I used to have a delusion that my preferred language was mighty important and its libraries should be packaged in every major distribution.

Grey line

For some special groups & applications to may be considered acceptable to expect special dependencies. If the environment is too dynamic and the target audience is known to be skilled (e.g. scientific groups) a blur of the above is reasonable.