And it's very easy on Linux to provide a source tarball and let the distro packagers do all the work for you. Plus, you know, static linking exists on Linux too, it's not something that only Windows can do.
- Your app isn't licensed in the way you like
- You don't want to provide the source code to your app
- They don't find your app interesting enough
- They don't agree with your app's policies
Static linking is a much better response for actually getting the program running on Linux systems but this still leaves out the "is there a way I can package it once for Linux" problem.
Now if it's a CLI only utility/service type tool it's a different story.
# dpkg-deb --build ./src/ mydeb.deb
Or just distribute a tar with your application.
I used to have to distribute a cross platform java progam. It was horrendous creating the MSI on windows. The linux and osx versions were trivial
Deployed by apt/yum/mdm andslme crappy windows thing. The latter was the problem.
It's not hard to make a static binary.
On the other hand most of the "software" I write - mainly shell scripts - includes things like apache configuration, requires other applications (like apache, iperf, tcpdump, lldp, etc)
I want to deploy these to multiple boxes, I want them versioned, I want them easy to update, I want to know what version is installed. All of this is handled by a 10 line config file in a .deb.
Long story short, it wasn't possible. Because the latest versions of Ubuntu and CentOS at the time used different versions of glibc which were mutually incompatible.
> Static linking of glibc is not supported on Red Hat Enterprise Linux.
https://developers.redhat.com/blog/2016/02/17/upgrading-the-...
:/tmp$ file ffmbc
ffmbc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
statically linked, for GNU/Linux 2.6.15, BuildID[sha1]=...., stripped
:/tmp$ ldd ffmbc
not a dynamic executable
ldd (GNU libc) 2.12 (Centos 6.9)
ldd (Ubuntu EGLIBC 2.19-0ubuntu6.14) 2.19 (ubuntu 14.04)
ldd (Ubuntu GLIBC 2.23-0ubuntu10) 2.23 (Ubuntu 16.04)