Due to the diversity of Linux distributions, it is quite common for programs to be distributed in source format together with scripts in order to assist the configure, make, make install sequence.

When it comes to commercial programs, however, distributing the source is usually simply not possible.

So if anybody wants to sell a program and deploy it to a Linux environment, what should he do? How is this normally done?

closed as too broad by gnat, thorsten müller, user40980, ozz, Jim G. Sep 26 '13 at 3:21

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Take a look at dev.mysql.com/downloads You will see that the vendor compiled many different flavours of linux into many different packaging formats. Each is considered the best by a different set of people that do not seem to converge to consensus. – bbaassssiiee Sep 21 '13 at 7:27
  • I see, they use packages based on things like RPM or APT. Doesn't that include the source though? My impression is that you can't simply compile something, distribute the binary and see it work on any Linux flavour. – Gigi Sep 21 '13 at 7:30
  • An RPM does not need to contain source code. You can add binaries, libraries, media, upgrade scripts, whatever you like, and except the source code. A spec file is used to create RPMs, rpmbuild is the command to use. In the spec file you list the contents and meta data. Macros for 6 lifecycle stages are optional. You can pack source code if you want to, and also you can compile during install if there is a need for it (i.e. kernel dependency or firmware), but that is entirely optional. – bbaassssiiee Sep 21 '13 at 7:48
  • 1
    In fact, rpms very rarely contain source code. srpms, on the other hand... – itsbruce Sep 21 '13 at 9:09

It is done the same way it is done on any OS; by distributing packaged binaries.

configure; make; make install is still commonly seen in instructions for open source software because it is very portable and often allows you to install software written for generic UNIX rather than Linux specifically. Compiling the software on the destination machine (or one similar to it) means that the compiler will use the header files (and the linker find the right libraries) tailored to the specific OS and (in the case of Linux) distrubution. The GNU Autoconf configure scripts can detect a wide variety of variations in UNIX operating systems and try to choose the most appropriate libraries and compiler options for the system.

Compiling from source also allows the end user to choose specific optimisations, if they want. Oh, and change the code any way they want, too (although the license may restrict how they can then redistribute it).

If you want to distribute commercial software, compile it first and distribute the result. However, you may have to generate more than one version, depending on the complexity of your package. You might have to create one version for Red Hat and derivates, another for Debian and derivatives etc; for each distribution, you may well have to generate different packages for the different versions still in common use (one for RHEL 5, another for RHEL6) because of incompatible libraries. Or you might have to build one version for kernels older than a particular version, and another for versions since that, if a kernel interface important to your application has change. You might have to build packages for each of these permutations (distribution + distribution version + kernel version). You have to do this because binaries cannot adapt - that's what the source is for.

Not the answer you're looking for? Browse other questions tagged or ask your own question.