Berlin Packaging API
At the LSB face-to-face (December 2006) in Berlin, the various package manager maintainers and ISVs agreed on the need for a common API to allow non-package software installs to register their apps with the package manager. This need has been reiterated a few times, but with little progress.
This page is intended to help coordinate the creation of this API.
As a starting point, we may want to use Ian Murdock's summary to the packaging list.
Straw Man Proposal
Here's a simple mapping of the needs in Ian's message to a C API. Please add comments on the talk page.
All functions would return a boolean, reporting success or failure. It's an open question whether we should expose more information than this about the reasons for failure.
The API deals in "pseudo-packages", which look to the package manager like very simple packages. A pseudo-package has a name, version, and file list (manifest). Upgrades of pseudo-packages would happen by simply unregistering and re-registering the package with a newer version.
bool compare_dependency(const char *package_name, relation_t relationship, const char *version)
This function would take a dependency statement, consisting of the given package name, relationship (possibly implemented as an enum or set of constants, with values like LESS_THAN, GREATER_THAN, EQUAL, etc.) and version specification. It would return true or false, indicating whether the dependency is present.
While the API could, in theory, be used to query any package relationship, we should not encourage this. I can see two legitimate uses:
- Querying the LSB version (something like "lsb >= 3.1")
- Querying the status of packages provided by the vendor.
bool register_package(const char *package_name, const char *version, manifest_t manifest)
This function would register a "pseudo-package" with the package manager.
The "package_name" and "version" parameters should be obvious. The "manifest" parameter would contain the list of installed files that should be considered part of the package. I call it a "manifest_t" as a placeholder for the actual representation of those files; it could be a path to a manifest file in some format, an array of string filenames, a special struct built by the installer, or whatever.
The function would return a boolean reporting whether the registration succeeded or failed. Reasons for failure should be documented, and might include name conflicts, file conflicts, or other reasons. It's an open question whether the exact failure reason should be exposed via the API.
bool unregister_package(const char *package_name)
This function would unregister a "pseudo-package" previously registered with the package manager, identified by name.
For the purposes of this spec, it should not be allowed to uninstall real packages via this mechanism; in other words, the package thus unregistered should have been previously registered via this API.
The function would return a boolean reporting whether the unregistration succeeded or failed.