fyi. openSUSE Build Service is excellent, for packages without convoluted dependencies; I've been using it to deliver qtop for multiple distributions, with good success:
http://cern.ch/fotis/QTOP/
http://download.opensuse.org/repositories/home:/georgatos/
You can produce all packages via: a tarball-generating Makefile, then kick OBS for the rest.
The issue though gets more complicated if you have dependencies that have varying names across distros or, different packaging schemes (Boost comes to mind, which sometimes is broken up in pieces). If you have such situation, providing a universal solution is more tricky. AFAIK, in the later case you will need to deliver more programming skills, to automate the above.
If this is true, what is so special about dpkg that is not available with the other commands?
The other commands are not a package manager replacement, that's what makes dpkg so special. You can really extract the contents of all the package and drop it in your root directory, but that doesn't mean they will be working properly. You have no way of tracking dependencies, identify what package installed what files, post/pre installation and removal scripts, and many other nifty features that package managers provide.
What they meant with that paragraph, is, that in case you mess up big time, you can download the files, extract them and recover your system, as makeshift replacement for the proper tool:
This seemingly trivial property is important for portability and disaster recovery
So, the importance of DPKG is great, but they have put failsafes in place so that in case of disaster, you can recover fairly quickly.
Best Answer
In a strict sense a binary file is one which is not character encoded as human readable text. More colloquially, a "binary" refers to a file that is compiled, executable code, although the file itself may not be executable (referring not so much to permissions as to the capacity to be run alone; some binary code files such as libraries are compiled, but regardless of permissions, they cannot be executed all by themselves). A binary which runs as a standalone executable is an "executable", although not all executable files are binaries (and this is about permissions: executable text files which invoke an interpreter via a shebang such as
#!/bin/share executables too).A binary package in a linux context is an application package which contains (pre-built) executables, as opposed to source code.
Note that this does not mean a package file is itself an executable. A package file is an archive (sort of like a
.zip) which contains other files, and a "binary" package file is one which specifically contains executables (although again, executables are not necessarily truly binaries, and in fact binary packages may be used for compiled libraries which are binary code, but not executables). However, the package must be unpacked in order for you to access these files.Usually that is taken care of for you by a package management system (e.g. apt/dpkg) which downloads the package and unpacks and installs the binaries inside for you.
There isn't --
.debpackages are binary packages, although there are.debs which contain source instead, these usually have-srcappended to their name.Those are generally self-extracting binary packages; they work by embedding a binary payload into a shell script. "Self-extracting" means you don't have to invoke another application (such as a package manager) in order to unpack and use them. However, since they do not work with a package manager, resolving their dependencies may be more of a crapshoot and hence some such packages use statically linked executables (they have all necessary libraries built into them) which wastes a bit of memory when they are used.