Discussion: How do you distribute your applications?

[Wesbat]

Hello there. I am thinking about all the ways how to distribute my FPC-developed application. Windows is easy: an InnoSetup installer suffices nicely. Linux is a little trickier. FYI: I used this wiki page as my starting point.

My first attempt was an AppImage package. I wanted a solution independent of a third-party framework, while containerizing any dependencies (in my case, libsqlite) for a truly stand-alone experience (needless to say I did not succeed).

Moving on, I saw recommendations on these forums for 0Install. The process seems a bit daunting, and before I fall down that rabbit hole ...

I'd like to open a discussion to hear how you approach distributing your apps to end users. What is your preferred method to distribute for GNU / Linux? Do you opt for binary releases, or do you prefer to go the Makefile route and let the end users battle it out with the compiler?

Looking forward to your thoughts 

[Thaddy]

(in my case, libsqlite) for a truly stand-alone experience (needless to say I did not succeed).

Why? You can link SQLite statically. So then your executable does not have any dependencies.

[TRon]

What is your preferred method to distribute for GNU / Linux? Do you opt for binary releases, or do you prefer to go the Makefile route and let the end users battle it out with the compiler?

The way that the distribution prefer users to to distribute applications.

Thus explicitly not introducing other operating system methods to install applications.

[marcov]

Do you opt for binary releases, or do you prefer to go the Makefile route and let the end users battle it out with the compiler?

Usually we also deliver hardware with an OS. Then we provide binary updates for that distro.  If we don't deliver the distro, we don't deliver binaries.

Though admitted, our Linux releasing is rather limited. Mostly simple TCP/IP based applications that bridge between main embedded binaries on Windows and a company network.

For windows we deliver binary (standlone binaries for preinstalled machines, though the software requirements are rather limited)

[Wesbat]

Thanks all for your feedback. I appreciate the input, given how lost I feel on this topic.

Why? You can link SQLite statically. So then your executable does not have any dependencies.

I will certainly look into this as it sounds like something worth learning, thanks Thaddy.

The way that the distribution prefer users to to distribute applications.

Thus explicitly not introducing other operating system methods to install applications.

Indeed that is very sensible, thanks TRon. In other words packaging into .deb or .rpm, or providing a tarball with a Makefile for lesser known distros.

Usually we also deliver hardware with an OS. Then we provide binary updates for that distro.  If we don't deliver the distro, we don't deliver binaries.

Though admitted, our Linux releasing is rather limited. Mostly simple TCP/IP based applications that bridge between main embedded binaries on Windows and a company network.

For windows we deliver binary (standlone binaries for preinstalled machines, though the software requirements are rather limited)

That is very interesting, thanks for sharing marcov. That takes me back to when I first started working, we supplied hardware + software in a similar method, but now I just want to make my hobby project available to the general public 

[TRon]

In other words packaging into .deb or .rpm, or providing a tarball with a Makefile for lesser known distros.

Note that some distro's also consider something like flatpack or appimage these days. There are probably others as well. I simply don't bother investing time to figure out. If you are on Linux then you should be used to have the required skills and have (g/c/auto/whatever)make and gcc/java/python/rust/go/whatever_else installed and build a project from source.

More important in such cases is to have clear instructions about dependencies (or have a configure/make script (or otherwise) fix that for end-users) and build options/requirements.

But yeah, the default .deb/.rpm is what most are familiar with and which usually gets adopted quicker than the requirement to use/install/learn something else/new. On some setups it is not even possible/allowed to divert from the defaults.

[dbannon]

I make debs, rpm, zst (packman) and, to be sure also distribute a tgz ball containing the binary and few extra files along with a text file about how to manually install. x86_64, i686, armhf and aarch64 (Raspi and Apple).

I also make Windows and MacOS packages but Linux is where the issues lay !   Recently, I added AppImage because people kept asking for 'bundled apps' (and I don't like Snaps, Flatpack more demanding).  I have started documenting the AppImage process at https://wiki.freepascal.org/AppImage_Packaging . Its not hard but makes a 35Meg bundle.

And I makes a source package I submit to debian.

Don't forget you will almost certainly need to distribute more than just the binary. An icon, desktop file, man page, config files etc ....

I strongly recommend you don't do your final build on your working machine, I use a VM for the following reasons.

• The glibc issue, a binary made on eg Ubuntu 22.04 will not run on Ubuntu 20.04. Visa versa is fine.
• Having a relatively untouched building platform alerts you to any new library dependencies that may have crept into your dependency list.
• Its easier to have a single script that pulls a snapshot of src from github and builds most of the above in one run. Script as much as you can.

Davo