0install: a decentralised installer that leaves your distribution alone

A package manager that is meant to share the machine with another one

Zero Install is a decentralised cross-distribution software installation system available under the LGPL. It allows software developers to publish programs directly from their own web sites, while supporting features familiar from centralised distribution repositories such as shared libraries, automatic updates and digital signatures. It is intended to complement, rather than replace, the operating system's package management, and 0install packages never interfere with those provided by the distribution.

That last sentence is the whole design premise, and it is unusual. Most alternative package managers position themselves as a replacement, and then spend their effort on package databases, conflict resolution and system integration. 0install takes the opposite position and leans into it. It installs into a directory of its own, it shares a library with other programs when it can, and it leaves /usr/bin alone.

The two features that follow from that premise are the ones the introduction calls interesting. While it will share libraries whenever possible, it can always install multiple versions of a package in parallel when there are conflicting requirements, which is the behaviour a system-wide package manager cannot offer without conflicts. And installation is always side-effect-free, with each package unpacked to its own directory and no shared directories such as /usr/bin touched, which is what makes it ideal for use with sandboxing technologies and virtualisation.

There is a third feature that only makes sense in a decentralised system. The XML file describing the program's requirements can also be included in a source-code repository, allowing full dependency handling for unreleased developer versions. A user can clone a Git repository, build and test the program, and automatically download newer versions of libraries where necessary, without interfering with the versions of those libraries installed by their distribution, which continue to be used for other software.

The project is at 0install.net, is written in OCaml, and the licence is LGPL-2.1 with copyright Thomas Leonard and others, 2017.

Building the core from source with opam

0install is written in OCaml, and you need the OCaml build tools and some OCaml libraries to compile it. The easiest way to get the dependencies is OPAM, and you need opam version 2 or later.

    $ opam switch create 4.07.0
    $ eval `opam config env`
    $ opam install yojson xmlm ounit lwt_react ocurl obus lablgtk lwt_glib sha dune

Several of those are optional, and the documentation is specific about what each buys you. obus is used on Linux to add support for D-BUS notifications, installing native packages using PackageKit, and using NetworkManager to check the network status before doing background updates. lablgtk and lwt_glib provide a GTK GUI. And ocurl selects the C-based libcurl backend for HTTP, with the alternative being the packages cohttp-lwt-unix and lwt_ssl for a pure OCaml HTTP client.

That list is worth reading as a description of what the tool does on a Linux desktop. PackageKit integration means it can install native distribution packages when a dependency is better served by the distribution, D-Bus notifications mean the background update check tells you about itself, and NetworkManager awareness means it will not start downloading over a link that is not up.

If you would rather use your distribution's packages, the documentation gives Debian and Fedora command lines. The Debian one installs gettext, ocaml-nox, ocaml-findlib, the yojson, xmlm, lwt, ounit, curl, sha, obus, lablgtk2 and lwt-glib dev packages, and the Fedora one installs the equivalent set with the ocaml- prefix and openssl-devel.

Either way, the build and install is one command in the top-level directory:

    $ make && sudo make install

And there is a no-root variant that installs into your home directory instead:

    $ make && make install_home
    $ export PATH=$HOME/bin:$PATH

The documentation also notes that logging out and back in ensures PATH and the Applications menu get updated correctly, on Ubuntu at least. To try 0install without installing it at all, run make and then ./dist/files/0install --help.

The XML metadata format, and why no new packaging format was needed

The design decision that keeps 0install small is that it does not define a new packaging format. Unmodified tarballs or zip archives can be used. Instead, it defines an XML metadata format to describe these packages and the dependencies between them.

A single metadata file can be used on multiple platforms, among them Ubuntu, Debian, Fedora, openSUSE, Mac OS X and Windows, assuming binary or source archives are available that work on those systems. The metadata is what is portable; the archives are ordinary files.

That design is what makes the decentralised model practical. A developer publishes a tarball at a URL and an XML file describing it, and the file can say, in effect, that on Linux this archive and on Windows that archive both satisfy the same interface. The resolver then works from the metadata and never has to know anything about a repository.

The repository layout reflects a codebase with several products in it. There are opam files for 0install, 0install-solver and 0install-gtk, which are three separate packages, and the solver being its own package is the interesting one, because dependency resolution is the hard part and separating it means other tools can use it. There is a dune and dune-project for the build, a Makefile, ZeroInstall.xml, a binary-feed.xml.in, an install.sh.src, share/ for the completion scripts and other data, static/, src/, and CHANGES.md alongside the COPYING file with the LGPL terms.

The Makefile shows the three build modes it supports, and the comments in it are a good description of the project. A traditional install under /usr/local or the home directory, building a library for other 0install tools such as 0compile, and an in-place build for testing during development. The default target is all followed by test. It also documents the difference between the two kinds of output, since a plain make leaves a complete distribution in the dist directory containing the compiled binaries and a 0install binary feed which can be registered with 0install add.

The Windows build, and what a 2017 codebase means in 2026

The Windows story is where the age of the project shows most clearly, and the documentation is candid about it.

A C# Windows version of 0install is available at 0install.de. It uses some of the OCaml code internally, but adds its own user interface and has better Windows integration. So the primary implementation is the OCaml one, and the Windows path you are pointed at is a separate program built on top of parts of it.

Compiling the OCaml version on Windows is described as currently only really useful if you want to build it for use with the C# code. The instructions involve OPAM for Windows, the 64-bit graphical installer, and then running commands in a Cygwin64 Terminal. The commands are opam install depext-cygwinports depext, opam depext 0install, and opam pin -y add -k git 0install . The last one pins the local source tree as the package under development.

Three limitations are then listed plainly. The binary requires various DLLs to run, and cygcheck 0install.exe lists the ones needed, which are then copied from the mingw sys-root bin directory. The tests don't currently pass on Windows. And the native OCaml code cannot currently cope with archives containing executable files with the Unix X bit set, where the error is Incorrect manifest -- archive is corrupted, with the explanation that when the OCaml version runs under the .NET version, the .NET version sets the %ZEROINSTALL_EXTERNAL_FETCHER% environment variable to a .NET helper process which does the unpacking correctly. Patches to improve the situation are welcome.

The version history is a good indicator of the project's pace. The releases are v2.18 in August 2022, v2.3.16 in January 2023 and v2.3.17 in December 2025, and the last push was on 2026-06-04. The 2.3.16 to 2.3.17 gap of nearly three years shows how little changes between releases in a stable codebase, and the 2.18 to 2.3.16 jump shows that the numbering is not strictly sequential in practice.

None of that means the project is dead. The top level still carries an active CI setup with .travis.yml alongside .travis-extra-deps.sh and .travis-test-compile.sh for the platform-specific parts, an appveyor.yml for Windows, a .dockerignore, and a 0compile.properties file for the 0compile build path. The last commit in June 2026 shows maintenance rather than abandonment.

The honest summary is that 0install is a mature design from around 2017 that is still maintained in a low-key way, with an OCaml core that is pleasant to read and a Windows story that is a separate program with acknowledged rough edges.

Using it, and whatchanged as the safety net

The quick start in the README is worth reading because it shows the everyday model in three commands. To install a program and give it a name:

    $ 0install add rox-edit http://rox.sourceforge.net/2005/interfaces/Edit

And to run it, using the name you chose:

    $ rox-edit

The update model is background and lazy. When you run it, 0install will check how long it has been since it checked for updates and will run a check in the background if it has been too long. To check for updates manually:

    $ 0install update rox-edit
    http://rox.sourceforge.net/2005/interfaces/ROX-Lib: 2.0.5 -> 2.0.6

The output line is a library upgrade rather than an application upgrade, and the README points that out: this shows that ROX-Lib, a library rox-edit uses, was upgraded. This is the behaviour of a real dependency resolver, where the unit of change is often a dependency rather than the program you asked for.

The safety net is whatchanged. If an upgrade stops a program from working, use 0install whatchanged. This will tell you when the application was last upgraded and what changed, and tells you how to revert to the previous version:

    $ 0install whatchange

That is a capability most package managers do not offer, and it is a direct consequence of the side-effect-free design. Because each package lives in its own directory, an upgrade does not overwrite the old one, so reverting is a matter of pointing at the previous version rather than restoring a deleted file.

Shell completion is handled by the same install: a bash completion script lives in share/bash-completion and can be sourced from your .bashrc or added under /usr/share/bash-completion, though you may need a separate bash-completion package on some systems. For zsh, copy the script in share/zsh/site-functions/ into a directory in your $fpath. For fish, add the full path to share/fish/completions to $fish_complete_path. These completion scripts are installed automatically by make install.

Editorial conclusion

0install suits a developer whose users cannot or will not install from a central repository, and a platform engineer who wants programs installed side-effect free into their own directory so that upgrades and rollbacks never touch a shared prefix. It does not suit you if you want a package manager you will not have to build yourself, because the core is a source tree you compile with the OCaml toolchain, and the packaged binaries are old. Before you depend on it, note that the OCaml build path on Windows is described as only really useful for building it for use with the C# code, and that the tests do not currently pass on Windows.

Frequently asked questions

Official sources

1. 0install/0install on GitHub
2. License: LGPL-2.1
3. Project website
4. README
5. Releases