Shawn - comments below:
Thanks
JR
I'm confused here. The user is adding a new Repo and installing
packages from it, so it won't be the preferred authority at that
time, so how do we handle this? Do you want to switch this New Repo
to be your preferred one, that is not what I thought we should do. If
no repo is specified in the MimeType file then that is an error and
no packages will be installed.
We will always display to the user which Repo they are adding
packages from before they proceed, so this should be safe I would
have thought.
Well, there's a few complications to keep in mind. For example, I
know that pkg://authority/foo will install foo from the specified
authority. But what about the dependencies of foo? If those
dependencies are also provided by the preferred authority, will it be
installed from the preferred authority or from the specified authority
in pkg://authority/foo?
The only other option I can think of is to somehow express to the API
that a preferred authority only for the duration of the transaction.
This sounds like the right approach. We could pass an authority to
plan_install() so it can enforce this preferred authority restriction
for the transaction, and just give it a simple list of package names
without the package stem. Can you discuss this with Brock to see if we
can do it that way.
/Workflow for the user will be [2]:
------------------------------------------------------
xDesign is working on preliminary designs, but in essence I think
it will go like this:
- Click on Mimetype web link in browser
- Packagemanager is launched in WebInstall mode, so only a simple
WebInstall dialog is displayed to the user not the full PM
- WebInstall Dialog, lists out what is about to happen, if a new
Authority needs registered and what if any packages are about to be
installed. Click Cancel or Proceed.
- On Proceed, if new Authority required, popup New Authority
Dialog, which allows user to specify Authority name (though one
could be suggested from info in AuthorityInfo file) and SSL key and
cert if required. After this completes launch Install dialog to
install packages.
That leads to a double confirmation if all of the required
information about the authority has already been provided. I think
it would be better to:
* if all the required information has been provided, confirm the
action and provide a choice to:
-- edit the authority information and continue
-- immediately execute the requested action
-- cancel
Given that the user may always want to change the Name on their
system even if one is suggested by the authority I think the simplest
thing here is just to present the Add New Repository dialog to the
user every time, if the Authority is not registered on their system.
I think that seems reasonable behavior. When we get it up and running
we can play with it and see how it feels.
That seems reasonable if the authority did not previously exist, but
if it did previously exist, I think the flow I suggested might be
better. However, I leave this to your discretion.
I'll play around with it.
One remaining concern I have about the pkg_names aspect is that this
is likely to overlap with the functionality that was recently posted
about by Dan Price [1]. That means that the implementation for this
may change a lot in the future.
Well it would be easy to save selections from the GUI to allow this
type of functionality to be implemented. What we could do is save
them as a .p5i file, one per repo, so then anyone could use this set
of .p5i files to install the set of packages again. We can talk about
this when I'm over in the US if you and Dan are on the West coast.
We'd just need another api to support this:
save_authority_info(<AuthorityInfo File>, <list of package names>,
<path to .p5i file>)
As I understand it, it's actually possible for multiple authorities to
be in an authority/0 response. As such, I plan on supporting multiple
in a p5i file.
Ok if that's the case then I need a few extra things:
- The MimeType file needs to express a relationship between an authority
and packages to be installed for that authority, which presumably is not
a problem in JSON.
- Then we would change the API's return:
parse_authority_info(<path to mimetype file|origin_url>)
- Would need to return a list of tuples, each tuple containing an
AuhtorityInfo object and an optional list of packages to install
Cheers,
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
