What is the difference between creating .deb files and installing them and just running a .run file?
.deb files are packages for dpkg, the low-level Debian package manager (which is invoked under the hood by APT and its relatives). A
.deb file is a package for Debian or for a derivative such as Ubuntu or Mint.
Debian packages contain the files that belong to the package as well as a “control file” which describes the package's dependencies and other meta-information, and installation scripts that are executed when the package is installed, upgraded or uninstalled.
You can look at the content of a
.deb file with
dpkg -c and
dpkg -I. If you don't have
dpkg, you can use
ar t foo.deb to list the parts of a
.deb file and
ar x foo.deb control.tar.gz to extract the
control.tar.gz part (and similarly for other parts).
.run is not a standard extension. A
.run file is presumably something you can execute. It may install a program or do something completely different.
In general a .deb file is similar to a zip file, that contains files along with short scripts that can run post installation to add users, groups, etc. to the system after installation.
A .run file is usually either a single binary executable or a shell script that contains a binary blob that can be installed. If it's the shell script variety it will often times contain a binary blob that is often synonymous to a recursive zip file or tar file. In other words it will contain directory structures of files.
Other times this type of .run file will simply contain .deb or .rpm files which will get dumped out to the disk, and can either be installed individually, or the script that contained them, will dump them out to disk, and then attempt to install them using your system's package manager software.
An example of this would be if you download the Java JDK from Oracle. It's typically a single executable file that when executed will dump the .deb or .rpm files out to disk, and then install them using
the package management tools: dpkg,
Here's an example of what the download/installation would look like with one of these .run files. The extension is .bin, but this is simply cosmetic, the extension is of really no relevance other than to help users distinguish between the different types of files.
$ wget http://www.java.net/download/jdk7/archive/b125/binaries/jdk-7-ea-bin-b125-linux-x64-13_jan_2011.bin $ ./jdk-7-ea-bin-b125-linux-x64-13_jan_2011.bin
Here the above file will dump out packages for the various components that make up the JDK, after which you can install either all of them or just the ones that you need.
Do it this way allows for additional things to be done beyond just installing a package. For example Oracle has a license agreement that they want you to accept:
10.5 This Agreement is the parties' entire agreement relating to its subject matter. It supersedes all prior or contemporaneous oral or written communications, proposals, conditions, representations and warranties and prevails over any conflicting or additional te rms of any quote, order, acknowledgment, or other communication between the parties relating to its subject matter, including any Bi nary Code Licenses, Supplemental Terms, or other licenses contained within Licensed Software. No modification to this Agreement will be binding, unless in writing and signed by an authorized representative of each party.
Do you agree to the above license terms? [yes or no]
With this above installer you can see that it contains just a binary blob of directories of files:
Extracting... UnZipSFX 5.52 of 28 February 2005, by Info-ZIP (http://www.info-zip.org). creating: jdk1.7.0/ creating: jdk1.7.0/lib/ inflating: jdk1.7.0/lib/jexec creating: jdk1.7.0/lib/visualvm/ creating: jdk1.7.0/lib/visualvm/visualvm/ creating: jdk1.7.0/lib/visualvm/visualvm/modules/ inflating: jdk1.7.0/lib/visualvm/visualvm/modules/com-sun-tools-visualvm-attach.jar inflating: jdk1.7.0/lib/visualvm/visualvm/modules/com-sun-tools-visualvm-host-views.jar creating: jdk1.7.0/lib/visualvm/visualvm/modules/locale/ ...
In this case this type of installation is meant to not summon the package manager but simply to dump the contents out to a single directory tree so that you can move it around where ever you desire.
In production environments it's often the case that you don't want to use the package manager, but rather have more control over deployments. Perhaps you have several applications that you're deploying and they each require a different version of the JDK. Using this method you can have them all coexist more easily then say via the package manager.
$ pwd /home/saml/jdk1.7.0 [saml@grinchy jdk1.7.0]$ ls -l total 19308 drwxr-xr-x 2 saml saml 4096 Jan 13 2011 bin -r--r--r-- 1 saml saml 2487 Jan 13 2011 COPYRIGHT drwxr-xr-x 5 saml saml 4096 Jan 13 2011 db drwxr-xr-x 11 saml saml 4096 Jan 13 2011 demo drwxr-xr-x 3 saml saml 4096 Jan 13 2011 include drwxr-xr-x 6 saml saml 4096 Sep 29 10:57 jre drwxr-xr-x 3 saml saml 4096 Sep 29 10:57 lib -r--r--r-- 1 saml saml 9005 Jan 13 2011 LICENSE drwxr-xr-x 4 saml saml 4096 Jan 13 2011 man -r--r--r-- 1 saml saml 25379 Jan 13 2011 README.html -r--r--r-- 1 saml saml 20320 Jan 13 2011 README_ja.html -r--r--r-- 1 saml saml 15160 Jan 13 2011 README_zh_CN.html -r--r--r-- 1 saml saml 5348 Sep 29 10:58 register.html -r--r--r-- 1 saml saml 5645 Sep 29 10:58 register_ja.html -r--r--r-- 1 saml saml 4951 Sep 29 10:58 register_zh_CN.html drwxr-xr-x 8 saml saml 4096 Jan 13 2011 sample -rw-r--r-- 1 saml saml 19631790 Jan 13 2011 src.zip