Simplifying Publisher Configuration
By swalker on Feb 08, 2010
Changeset 1736 in the pkg(5) gate made the following changes:
11522 pkg should require publisher prefix to match repository information
7156 client image api needs image creation interface
12744 update_publisher over-zealously testing publisher validity
14203 image-create usage doesn't mention mirror / origin options
What changed?The pkg(1) client and the pkg.client.api will now attempt to retrieve publisher configuration information from package repositories. This information is used to auto-configure new publishers, validate configuration requests, and to update the configuration of existing publishers.
These changes were made with a focus on simplifying publisher addition and updates of existing publisher configuration.
Further improvements and additions to this functionality are planned for future releases.
Are there any pkg.depotd(1m) changes?While the pkg.depotd(1m) program did not change, clients are now more reliant on its correct configuration.
As already mentioned in the past, please be certain that you set the publisher.prefix property found in the repository's cfg_cache file correctly. The pkg.depotd man page contains instructions on how to set this property.
Please also note that the repository.origins and/or repository.mirrors properties should be set as clients will use these to automatically configure new publishers and to update existing publishers. You might also want to consider providing a description so that users have an idea of what sort of packages the repository contains.
Part of an example cfg_cache might look like this:
prefix = example.com
alias = None
origins = http://pkg-us.example.com/,http://pkg-ca.example.com/
mirrors = http://pkg-us-mirror1.example.com/,http://pkg-ca-mirror1.example.com/
How has pkg(1) image-create changed?The client remains completely compatible syntax-wise, so no changes to existing scripts are required, and behaviour when using the older syntax (other than validating publisher configuration) remains unchanged.
However, image-create now also accepts -p <uri> where <uri> is the URI of a package repository and example usage is as follows:
pkg image-create -p <uri> /target
When using this syntax, image-create will retrieve all of the publisher's configuration information from the target package repository and add all of the publishers it finds to the image.
How has pkg(1) set-publisher changed?The syntax of the set-publisher command remains backwards compatible, so no changes to existing scripts, etc. are required. However, set-publisher now accepts the -p option which accepts the URI of a package repository from which all publisher configuration information will be retrieved.
Any new publishers found in the retrieved configuration information will be added, while existing ones will be updated if the provided URI is already in the list of configured origins for the publisher being updated.
If a publisher name is provided, then -p will only use publisher configuration information that matches the provided name.
As an example, the old syntax to add the contrib repository might have been:
pkg set-publisher -g http://pkg.opensolaris.org/contrib \\
The new syntax is:
pkg set-publisher -p http://pkg.opensolaris.org/contrib
How has pkg.client.api changed?
Incompatible with clients using API versions 0-31.
The ImageInterface class has changed as follows:
- The add_publisher and update_publisher methods now validate the image's publisher configuration against the origins of the publisher. If any of the origins are found to not match, an UnknownRepositoryPublishers exception will be raised. If one of the new repository origins does not provide publisher configuration information or it is incomplete, a RepoPubConfigUnavailable exception will be raised.
The pkg.client.api module has changed as follows:
- A new method named image_create has been added. See 'pydoc pkg.client.api' for details.
The pkg.client.api_errors modules has changed as follows:
- UnknownRepositoryPublishers, RepoPubConfigUnavailable, and UnknownErrors expections have been added for use by the pkg.client.api. API consumers are reminded that they should catch all ApiException class exceptions, although catching specific exception subclasses for case-by-case handling in addition to that is acceptable.
Feedback is welcomed on the pkg-discuss mailing list on opensolaris.org.