John Rice wrote:
Shawn Walker wrote:
jmr wrote:
...
Note: The list of packages returned needs to have been setup so
/api.plan_install() /can work with them:
- If authority in file is the default authority the package list
entries just need to be, <pkg_name>
- If authority in file is NOT the default authority the package list
entries need to be, pkg:://<authority_name>/<pkg_name>
I question allowing files to override the user's preferred authority.
This could cause software to be installed that the user does not want,
or a newer version of a program.
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.
/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.
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.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
