I've been looking at some of the packaging interactions and
suggestions for enhancement we've been accumulating, and wanted to get
some feedback on a potential new operation (and file-type):
authority/0.
authority/0 is a new server operation that returns a formatted
response, with the following pieces of information:
- Repository's authority name, such as "opensolaris.org". Required.
- Repository package collection type. Either "complete" or
"supplement". Required.
- Repository full name. Optional.
- Repository description. Optional.
- List of one or more origin URLs for repositories. Optional, for
authorities that do not use the network protocol to distribute
packages. (We don't support that yet, of course.)
- List of one or more URLs for content mirrors. Optional.
- Update period. Optional, but recommended, so that clients can tune
their refresh frequency.
- License/terms of service URL. Optional.
- Registration URL/protocol. The pkg.sun.com/register service is
actually also a web service that clients can connect to to obtain a
key-certificate pair. It's more ad hoc than I would like, but could
be used to allow client integration under a specific
"com.sun.pkgcert" tag while we look for some more general facilities.
Some additional, optional fields I've been wondering about:
- Repository nickname(s). We slipped into using a nickname for the
"extra" repository for ease of typing, even though it should be
"extra.opensolaris.org".
- List of related authority/origin URLs to assist discovery of
additional dependencies. Right now, we've only got supplemental
repositories dependent on opensolaris.org packages--but multiple
level of supplementary repository seem probable, as publishers
acquire reputation about the stability of their packages.
Impacts:
0. The authority name is set by the publisher, and is not left to the
client. So
pkg image-create -a opensolaris.org=http://pkg.opensolaris.org/dev \
/tmp/myimage
is equivalent to
pkg image-create -a http://pkg.opensolaris.org/dev /tmp/myimage
1. The authority values in cfg_cache become overrides. For the most
part, the cfg_cache values become unnecessary. (Need input about
full name and description from Tom M, since Update Center is the
primary consumer of these values.)
2. The notion of having multiple, presumed identical origin URLs is
to allow the client transport subsystem to have more options in
calculating an optimal retrieval (as multiple content mirrors also
does).
3. The updatemanager notifier is expected to adjust its retrieval
period based on the authority's update period.
4. pkg(1) and packagemanager(1) are expected to make the license
available, and to integrate the registration service, if of known
type, to allow interactive assisted certificate retrieval.
5. The return value of authority/0 is useful as a standalone
document for bootstrapping access to an authority. That suggests
that the return value should be useful in a file form. We've used
XML with success/controversy in other places for properties like
this, but we could also use YAML or make a mini-language.
Assuming we have a document format, we should introduce a MIME
type, like application/vnd.opensolaris.pkg-authority (or
application/x-pkg-authority), and a standard suffix, like
.pkgauth (or something).
At that point,
pkg set-authority -a file_or_url
seems to become a useful extension. (pkg(1) is not currently,
however, an ideal client for "one click" actions out of the
browser, so we probably need to have a small GTK+-based helper as
well.)
There's probably more we can do with this operation, so ideas and
feedback encouraged.
Cheers
Stephen
--
s...@sun.com http://blogs.sun.com/sch/
_______________________________________________
pkg-discuss mailing list
pkg-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
