Orbifx's logarion

Distributing software

| | | topics: computing | 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 other developers, but there is a grey line too.

General public

Applications & runtime libraries.

Developers

Development 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

General 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).

Developers

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.

Notes

Big dependencies