Greetings all,
Last week Shawn and I were talking about why publisher continued to be a
confusing issue for our users. We came to the conclusion that one reason
that users were having problems was that we were conflating concepts in
the items we give a user to manipulate.
We ended up with the following proposal/attempt to clearly explain our
model. (Note, please don't consider
There are three distinct entities, publishers, streams, and
repositories. Publishers are the entities who put together
distributions, sign packages, etc... Specifically, they distribute one
or more streams (or trains or whatever term we settle on. dev and
release are two examples of streams for the opensolaris.org publisher.).
Repositories are simply collections of packages, possibly from multiple
publishers and multiple streams from those publishers.
Right now, what we're really giving users the ability to maipulate is
repos. Sure, the command is called "set-publisher" but we assign a
specific url which corresponds to a specific respository. I don't think
it's surprising that this confuses users. Further, to change from
release to dev (for example) we tell them to use set-publisher to change
the url of the publisher.
What we suggest instead is that our UI reflect our model, rather than
conflating our abstractions. We suggest that a publisher (optionally)
have a default stream, and that each stream (optionally) have at least
one default or known repository which holds (at least) all packages in
that stream of that publisher. So, a user starting with an empty image
would do "pkg set-publisher opensolaris.org http://pkg.opensolaris.org";
(for example) and the image would be set up to use the release stream of
pkg.opensolaris.org and would know about one repository (say
http://pkg.opensolaris.org/repo).
After a while, the user decides that they want access to the packages in
contrib. I assert (for the purposes of this example) that contrib would
be published by opensolaris.org (ie, they would sign the manifests), so
the user would do "pkg add-stream opensolaris.org contrib". That would
allow them to install packages from contrib (since either the default
repo for contrib would now be known to them or the contrib stream
packages in pkg.opensolaris.org/repo would now be available depending on
how we decided to organize our repos). Part of what "pkg add-stream"
would do is ensure that the contrib stream is not known to be
incompatible with the streams currently active on the system.
Let's say that Sun (as opposed to opensolaris.org) publishes the
packages currently in Extras. The user would add Sun as a publisher,
then add the Extra stream.
If the user tried to add the release stream from opensolaris.org while
the dev stream was active, pkg would error and inform the user that
those two streams were incompatible according to the publisher. The
publisher could define those incompatibilities both for streams it
produces and the streams of other publishers. This is how the support
stream would be handled since it (at least right now) seems to be
published by Sun, rather than opensolaris.org. While within publisher
incompatibilities might be common, between publisher ones should be rare.
Streams are comprised of packages, and other streams. For example, once
we've broken up our consolidations to some extent so that entire no
longer exists, we imagine opensolaris.org delivering a dev stream which
corresponds to what dev is today. The dev stream though will consist of
multiple streams, dev-on, dev-sfw, dev-gnome. Similarly, the release
stream will consist of multiple streams, rel-on, rel-sfw, rel-gnome,
etc... The dev-on stream would have an exclude dependency on the rel-on
stream (and the other way around). This allows users to chose to run the
dev-on kernel, but the release gnome bits, within the contraints imposed
by specific package dependencies.
The on-disk package of the future would include the information that
would otherwise be retrieved from the publisher upon installation.
That seems to cover most things. We're suggesting that streams live in
the package namespace, like publishers do.
We also have some ideas of what the GUI interaction should look like,
but we'll save that for another proposal if we decide that what we've
laid out seems like a reasonable way to go.
Thanks,
Shawn and Brock
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
