This answer explains
setup.exe files for installing an application on Windows.
Are there equivalents to
.msi and to
setup.exe files in Debian or Ubuntu? Do
.deb package files correspond to
setup.exe or something else?
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.Sign up to join this community
Probably closer to an MSI installer than a
.deb package includes a tree of files to copy into the filesystem, as well as a collection of pre- and post-installation hooks to run (among other things). The hooks can effectively do anything on the system, including something I don't think I've ever seen on Windows: adding users for a system service. One thing they can't do is install another
.deb package — the database is locked during installation, so this can only be achieved through dependencies. Installing a
.deb package then produces entries in a central database of installed packages for ease of maintenance.
ttf-mscorefonts package is interesting in that the package itself contains only a script to download and install the fonts. This script is executed in one of these hooks.
setup.exe might be downloading a progam's source code from the project's homepage, then running
./configure && make && sudo make install, or whatever other method the authors decided to use. Since this method does not add the package to the database of installed programs, removing it later can be much more difficult.
Another difference is that a
.deb specifies its dependencies, so proper installation can be guaranteed. As far as I know, in the Windows world an MSI cannot cause the installation of another MSI, so
setup.exe is typically used for this kind of dependency tracking. Several comments note that MSIs can name dependencies, but since there is no central database of MSIs like there is for
.deb packages, missing a dependency will just cause a failure to install.
.deb is sort of in between an MSI installer and a
setup.exe. The package can do whatever it wants during its pre- and post-installation hooks, can name and usually find its own dependencies, and leaves a record of its installation in a central location for ease of maintenance.
Single-file binary installers I have seen on Linux were
.sh files which contained a shell script concatenated with a binary blob, like this:
#!/bin/bash tmpdir=$(mktemp -d /tmp/installer.XXX) tail -n +6 "$0" | tar -xJf - -C "$tmpdir" || exit 1 sudo "$tmpdir/setup.sh" rm -rf "$tmpdir" exit [binary content follows]
This is essentially equivalent to a
setup.exe which also self-extracts to a temp folder and runs the real installer from there.
A .run file is normally a custom made program which needs to be executed in order to install a program. these are not supported generally as they don't track where files go and don't normally provide an uninstall method. there is no way to be sure what the script will do to your system so they're considered unsafe.
They are close to the windows exe file and as such come with the same issues.