What is the Universal Package Registry?

Universal Feeds and Packages are "lightweight" and have few built-in features in themselves. This design has allowed them to be used for all kinds of packaging problems, such as application delivery, Inedo's product extensions, and even private Bower packages.

When developing a package-based solution, the question often arises, "What packages are installed or used in this particular context?" This is where the Universal Package Registry comes in, a local package registry designed specifically for Universal Packages. 

Background: Other Local Package Registries

All packages, whether in universal format or not, are essentially zip files containing the contents (i.e., the actual files you want packaged ) and a metadata file describing the contents. Once the contents of a package are unpacked and installed in a directory, there is no easy way to find out what package that content came from, or if it came from a package at all. This is where a local package registry comes into play.

Different package managers use different mechanisms to represent a local registry. Some store the entire package, others store only metadata about the package, and each approach has advantages and disadvantages.

For example:

• The local registry for MSI (Microsoft Installer) is comprised of an installation cache directory (containing the MSI files installed) as well as various entries in the Windows registry.
• The NuGet local registry is comprised of various package cache directories and a packages.config file stored in the root of a project file that describes which packages are used.
• APT (Advanced Package Tool for Debian) maintains a directory of package-related files in /var/lib/dpkg/info, including MD5sums of each of the various installed files and the executable scripts that would be run before and after installation.

However, in all cases, the packages registered vs. packages installed are not enforced by the package manager or operating system. You can consolidate the data in the local registry if needed, or delete files that were originally installed by the package manager.

Designing the Universal Package Registry

The Universal Package Registry was developed with the realities of other local package registries in mind. 

• Well-defined specification - this allows a variety of tools (not just an API or CLI) to read or write data
• Data only - there is no attempt to automatically reconcile registered vs. installed packages
• Compliance-driven metadata - provides a common mechanism to indicate what installed a package and why
• Any additional metadata - for compliance or other reasons, you can add additional package metadata

A Universal Package Registry may also include a package cache. There are three common uses cases for this:

• Auditing - to verify or compare the original contents of the package registered versus the files installed on disk
• Repairing installation - if an installed package has been corrupted (a file at the installation location has been modified or deleted), the package can be reinstalled without requiring a connection to a Universal Feed 
• Staging packages - package files could be copied to the cache ahead of installation to allow for rapid deployment of newer versions