From the Package Manager standpoint in this scheme:
Users will either use pre configured Publishers on their system and add
Publishers to their system via:
- Clicking on a .p5i file
- Using File->Add Publisher which just takes a Publisher URI
In the last two instances, we are assuming if Trust information is to be
surfaced for a given Publisher we will prompt the user to ask they if
they want to Trust this Publisher and add it to their list of Trusted
Publishers, which means they then trust all streams from that Publisher.
We will need API support for all of this which is yet to be designed so
I will park that for now.
Once a user has a Publisher on the system they can then install packages
from its streams:
- In the Main PM View (what you see when PM is launched) we currently
list Publishers in a drop down combo, this would need to list
Publisher-Streams, which users can choose to search/ browse.
- In Manage Publishers we would need to figure out how to let users
interact with a given Publisher, its Streams (choosing which stream to
use from an incompatible set), which streams are active and for each
stream the ability to access its underlying repository information to
allow things such as the manual addition of mirrors. We'd also need to
allow for nested streams. All of this needs to be designed, but for the
most part users should not have to go anywhere near Manage Publishers to
have their system functioning with a reasonable set of Publisher-Stream
defaults, all defined by the initial Publisher payload fetched when the
Publisher is first added.
We currently allow users to search on a single Publisher or All
Publishers, which in this new model would be a single Publisher-Stream
and All Publishers.
With regard to user feedback, given the confusion that users seemed to
have with Publisher, I am not sure how they will cope with
Publisher-Streams and would favor just referring to this
Publisher-Stream couplet in the Main PM View as a Package Source which
clearly describes what they are.
As I'm off for a few weeks I will need to drop of this discussion, but
look forward to seeing what turns up over the next few week.
JR
Brock Pytlik wrote:
John Rice wrote:
Brock Pytlik wrote:
Tom Mueller wrote:
Brock Pytlik wrote:
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.
About repositories - first, I'm assuming that there is a
distinction between a pkg.depotd process and a repository. A
repository would be identified by a unique URL, but a pkg.depotd
process might eventually service multiple repositories. Is that
right?
No, I think we're suggesting moving to a model where there's a
one-to-one mapping between pkg.depotd process and a repository. But
that depo/repo/process might serve up packages from many streams and
many publishers.
Essentially, we want to move to a model where a repo/depo is just a
container that hands out bits of packages to clients as needed. In
short, the average user should never need to care what repo(s)
they're connected to.
So from a users standpoint instead of telling them about Publishers
in the main UI we would change this to something that couples
Publishers and Streams like:
Package Source: opensolaris.org-release
Package Source: opensolaris.org-contrib
Package Source: Sun-extra
I'm not sure what you mean by the "main ui". In general, I don't see a
reason to show a users the streams by default, but then I probably
wouldn't show them the publishers by default in the main window either.
In the Add Publishers the user would specify a URI for the Publisher,
but after that they really shouldn't be messing with a Repository URI
as this is just part of the internal plumbing a Publisher and its
streams are using. Is that right?
Your statement's a little confusing. Ideally, a user should never need
to know about a repo URI at all. They would just add a publisher with
its uri.
So in Manage Publishers, you would list Publishers and their streams,
if a stream was incompatible such as dev and release, we would need
to flag this to the user so they could choose which of these
incompatible streams to use, but in general the Publisher metadata
will indicate what should be the active streams by default and for
the general users they need never worry about having to choose them.
I think that's probably making too firm a statement. Everything should
work without a user needing to change a stream. However, since a
publisher may deliver multiple, compatible streams, a subset of which
are enabled by default, a user may well need to add (or remove)
specific streams to get the packages they want.
I assume all this rework is not targeted for 2010.02? If it is
there's going to be a lot of rework on the GUI side for the Add and
Manage Publishers and presumably on the CLI side as well.
I have no idea about schedules, or even if we'll go this way at all.
We (Shawn and I) put the idea out there for discussion because of what
we've observed from users.
Brock
JR
[snip]
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
