[Shawn requested that I send this to the list. The following is pretty
much the initial contents of defect #10213, slightly reformatted for
72-column wrapping, and a couple of typo fixes. -Nico]
When updating from 2009.06 to 117/118, a colleague (Will Fiveash) and I
tried different approaches. I added a publisher with /dev's origin and
made it the preferred publisher, my colleague changed the origin of the
original opensolaris.org publisher.
The CLI had no problem with my approach. The GUI did: it did not show
updates as being available. It seems that the right way to do what we
were trying to do is to update the origin of the original publisher,
rather than to add a publisher. This seems counter-intuitive.
This problem did get me thinking about the publisher metaphor. It seems
incomplete.
Consider packaging/distros as compared to book publishing:
- pkgs are like books
- pkg versions are like editions
- full pkg FMRIs are like ISBNs
- the entity that builds a pkg is like a book's publisher (and/or
printer)
- repositories are like libraries and book stores
- individual developers/project teams/communities are like book authors
- there is no book publishing analogue of metaclusters, releases or
"builds"
- libraries and bookstores can and do have multiple editions of
books, much as repos have multiple versions of pkgs, but it's hard
to imagine that one might have a /dev and /release libraries,
mostly because of the lack of a book analogue of metaclusters.
But the current IPS notion of "publisher" is purely local, whereas in
book publishing the publisher is not at all local -- every book tells
you who its publisher is.
When manifest signing is added to IPS this issue will gain importance.
The entity that signs a pkg will need a representation -- publisher or
"printer" seem like good analogues of that entity -- and it will not be
a purely local concept, as publisher seems to be now.
Perhaps what should happen is that a few pkgs should deliver publisher
definitions (including manifest signing certificates, and/or trust
anchors for repo servers). And pkgs should name their publishers. Then
users need only manage publisher preferences and enable/disable.
But that would get us into the question of what distinguishes /release
and /dev from each other. Today /release appears to be a subset of
/dev; when a release is made the "head" versions of pkgs and
metaclusters from /dev are added to /release. That would mean they have
the same publisher, if publisher maps to "entity that signs manifests",
unless manifests get re-signed in the /dev->/release move. So the
distinction seems to come mostly from what's in those repos, rather than
pkg/metacluster metadata. That too seems odd. If we kept the
distinction between /dev and /release as metadata served by the repos,
then we wouldn't necessarily need separate /dev and /release repos
(though we'd still want separate /contrib, /pending and /extra repos,
for various reasons).
In short: it seems to me that "publisher" and the distinction between
"release" and "not a release" should be first-class, non-local, non-
accidental metadata. Publisher information should be published by the
publishers themselves, and "release" versus "dev release", "alpha",
"beta", "release candidate" and so on should be more like tags (in the
version control sense) on metaclusters (possibly as metacluster FMRI or
version naming conventions).
The resulting UI should be simpler:
- To add publishers just install the pkgs that define them. (This may
require asking the user if they really want to do this when the
publisher's manifest signing cert cannot be validated to some trust
anchor such as, say, another publisher's CA cert.)
- To add repos and mirrors the user could manually enter/paste their
URLs, but origin and official mirror lists could and should be
delivered by pkgs as well.
- To image-update to a particular build, alpha, beta, RC, or release to
install/update to, just pick the one you want from a list. This, in
particular, has the benefit that one could install systems to earlier
builds, which is useful when providing support to customers with such
systems.
(Right now one cannot do this with the GUI except by modifying the
origin, and replacing mirrors, of the main publisher, and because we
don't have per-build/alpha/RC repos, there's no easy way to update to
a specific build/alpha/RC -- just the latest to be found in the repo
you've set the origin of the main publisher to.)
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
