13

What is the difference between creating .deb files and installing them and just running a .run file?

Jeff Schaller
  • 67,283
  • 35
  • 116
  • 255
Mandar Shinde
  • 3,236

2 Answers2

12

.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).

Red Hat (and relatives such as CentOS and Fedora), SuSE and others use rpm, a different format with similar characteristics. There are others on other unix systems.

.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.

Gilles 'SO- stop being evil'
  • 829,060
9

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, apt, yum, or rpm.

Example

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

References

Community
  • 1
slm
  • 369,824