Zero Install: Roadmap

Roadmap

This document explains what we've done and where we're going with future versions.

Despite its pre-1.0 version number, Zero Install is currently used by a large number of people, as it is the preferred method of installation for ROX, and is generally quite robust.

File format stability
Completed features
Features planned for 1.0
Other possible features

Vote on ideas!

File format stability

Although we have not reached the 1.0 release, the injector has a very good record of backwards compatibility. In fact, you can run Edit with the XML interface file used to demonstrate version 0.2 of the injector (released 2005-03-14) on the very latest (0.22) version of the injector. The only incompatible change was between versions 0.1 and 0.2! Of course, it doesn't work the other way; interfaces designed to work with later versions of the injector will use features not available on older versions.

Completed features

This is a quick overview of the major features added to the injector. See the release notes for a much more detailed list.

Dependencies, graphical interface, user-set policies: Since 0.1
Updating over HTTP, GPG signatures: Since 0.2
Pass options to programs: Since 0.5
Create alias scripts: Since 0.7
Automatic public key fetching: Since 0.8
Allow symlinks: Since 0.10
RPM packages of the injector: Since 0.13
Local interfaces and adding additional remote feeds: Since 0.14
Support for architecture-dependant binaries: Since 0.15
Additional feeds in interfaces: Since 0.17
Support FTP downloads of archives, XML signatures and extracting from RPMs: Since 0.18
Icons for interfaces, graphical cache explorer, and 0publish command to help with creating interface files: Since 0.19
Recipes: Combine several archives to create a single version. Since 0.20
Restrictions on suitable versions of dependencies: Since 0.20
Extracting from Debian packages: Since 0.20
Support for other secure hashes: Since 0.20
Support for extracting from Autopackage and zip archives: Since 0.21
Secure local copy (checking the digest): Since 0.22
Compile a binary from source: If a binary doesn't exist for your platform, the injector should be able to compile one from source for you. This should include downloading any necessary compilers, headers and build tools using Zero Install. The resulting binary should come with an automatically-generated interface file, ready for publishing the binary on the web. The archive should also include a provenance file listing the exact versions of dependencies used to build it, allowing it to be recompiled in the same environment later. Supported since version 0.23.
More flexible version numbering: The injector only supports a list of dot-separated integers. It would be useful to support some common modifiers, e.g. "1.0-pre1", "2.0.0-rc3", "5-post2". Since 0.24.
Extracting from Cabinet packages: Since 0.24
Extracting from .tar.lzma and .tar (uncompressed) archives: Since 0.25
Background checking for updates: Instead of making the user wait while we check for updates, start the program immediately and check in the background [ screenshot ]. Since 0.26.
Automatic secure sharing of downloads: If two users ask to run the same version of a program or library, it is only downloaded and stored once. The users don't need to trust each other; only genuine unmodified copies can be shared. See the sharing page for details. Since 0.26.
Bug reporting: Generate useful information for bug-reports, since we know exactly which version of each library was being used. 0compile already supports this if a build fails, but we could do something similar when running programs, too. Right-click on a component in the GUI to use this. Since 0.26.
Native package manager integration: If a Zero Install package requires a library, and the user already has a suitable version installed with another system (APT, RPM, etc) then the injector should be able to use that version. This would save unnecessarily downloading and storing a second copy of the library. The user should still have the option to get the library through Zero Install if they want though (e.g., if they want to try a newer version). See Distribution Integration for details. Since 0.28.
RPM integration: As above, but for RPM. Since 0.31.
Implementation bindings: In addition to attaching bindings to dependencies (which tell Zero Install how to tell a component about where its libraries are), it is now also possible to attach bindings directly to implementations (to tell them where they themselves are located). This simplifies packaging certain programs. Since 0.31.
Mirrors for feeds: Run a public mirror that periodically fetches the latest versions of feeds and makes them available from a single site, so that 0launch will download from the mirror if the upstream site becomes unavailable. Since 0.33, 0launch will download from the roscidus.com/0mirror mirror site if a feed takes longer than 5 seconds to download.
Manage applications added to the menu: Provide built-in support for editing and removing launchers added to the GNOME and KDE menus. Since 0.34.
Multi-arch support: Many newer computers can run both 64-bit and 32-bit applications. However, each process must be made up of components (libraries) of the same type (a 64-bit program requires all 64-bit libraries, a 32-bit program requires all 32-bit libraries). Since 0.35.

Features planned for 1.0

Automatic cache cleaning: The injector can keep all versions of all libraries on disk at once. This is useful, but there should be a way to clean out ones that aren't needed any more to free up disk space. Individual versions can be removed easily enough via the cache explorer, but it should be more automatic, a bit like "apt-get autoclean" or deborphan. In particular, we need a way to remove a version which was shared between multiple users safely (i.e. only remove it once no user requires it).
Mirrors for archives: If a download site is unavailable, switch to another mirror. Support sf.net mirror system, custom mirror systems, coral cache, etc. May need to show sponsor logos during the download. See also: Metalink
Optional dependencies: The interface file format only allows 'required' dependencies at present. It should also support the 'recommended' (optional and selected by default) and 'suggested' (optional and unselected by default) relationships.
Display release notes: The injector tells you that a new version is available, but it doesn't say what changed! At the very least, it should provide a link to the program's release notes on the web. [ Discussion ]

Other possible features

Plug-ins: It should be possible to add additional interfaces to a program's dependencies list. For example, you could add the interface for a French dictionary to a word processor to let you spell-check French documents. This would usually require some support from the application itself. A plug-in is a more general type of optional dependency; one which isn't listed in the main interface file at all. [ Discussion ]
More meta-data: License terms (and warn about incompatible licenses?), mailing list address, where to send bug reports, etc.
Peer-to-peer downloads: The tricky bit about P2P is normally the free-text searching, but we already know the secure hash of the manifest we want, and when we get it we have the hash of every file we need, so this should be easy! The idea is that if someone on your local network has already downloaded a program, you can get it from them automatically. See 0share for current experimental version.
Binary patches: We have the secure hash of the currently-cached versions, so we can check that they're unmodified. In that case, we could just download a delta to the next version rather than getting everything again. 0publish should create these deltas automatically. Rsync may also be an option for some sites. [ Discussion ]
Kiosk mode: The system administrator can restrict what software users can install using Zero Install (white-list interface URIs or trusted public keys).
Third-party sign-off: A distribution can sign an upstream release ("Certified for use with SuSE 10.2", etc). Users can set a policy to run only approved versions by default. Or, a third-party could provide additional input to the hints box (the injector's GUI contains a built-in "Unreliable hints database", but a commercial organisation could offer a real service).
Sandboxing: Provide better integration with sandboxing systems such as Plash. It should be possible to trust keys only in a limited way, so that such software must run in a sandbox. Sandboxed software must still be able to run other programs through Zero Install, adding them to the cache as needed in a secure fashion. [ Discussion ]