Thanks for the feedback Shawn, some comments below: JR
Shawn Walker wrote: > John Rice wrote: >> Stephen has posted about the authority/0 action against a depot >> server that would return authority info to allow a client to setup >> and configure the authority. In the form of the standalone document >> format, I'd like to extend this to allow packages to be included for >> install. >> >> Suggested Mimetype to cover both authority and package installs >> (changed from pkg-auth and .pkgauth): >> Mimetype: application/vnd.opensolaris.pkg-info >> Suffix: .pkginfo > > I'd prefer a shorter extension, and as others have already pointed out > in past discussions, ".pkg" is currently used by several other > software management systems [1]. As such, it is my belief that > ".pkginfo" implies a link to one of those other systems. The .ips > extension is already taken [2] as well. > > What about ".p5i" for pkg(5) info or some other extension? I have no strong opinion either way, we just need to agree on one. Who can make this decision - Stephen? > >> .pkginfo supported fields from Stephens authority/0 mail: >> ------------------------------------------------------------------------ >> authority_name: Required >> authority_fullname: Optional > > What if the authority name here conflicts with an authority they > already have? Will that update the mirrors and origin_urls of that > authority? > > I don't think this information should be required since if the > origin_url(s) points at a depot server that supports authority/0, then > we can get this information automatically. Currently we are checking the installed authorities on the machine and using the origin_url as the key, irrespective of the authority_name. I took "authority_name: Required " from Stephen's proposal, so I'll leave him to explain why he thought it should be required. If we are moving to the repo owner specifying the authority_name then this could make sense, otherwise I would prefer to stick with using the origin_url as the key and change this field to Optional. > >> repository_nickname: Optional > > What if the nickname conflicts with an existing one? If it conflicts then this should be apparent in the Add Authority dialog and the user would have to change it before being able to proceed with the addition. > >> collection_type: "complete" or "supplement". Required. > > I don't think this information should be required since if the > origin_url(s) points at a depot server that supports authority/0, then > we can get this information automatically. > >> origin_urls: one or more Required. > > What if the origin_urls of the new authority are the same as an > existing one? What problems will that create for the user? As with above comment if they are the same as an existing one on the system then the assumption is that the authority is already registered on the system, irrespective of the authority_name that has been proposed. > >> related_origin_urls: Optional >> mirrors: one or more, Optional >> update_period: Optional >> license_url: Optional. >> registration_url: Optional >> registration_protocol: Optional >> pkg_names: list of package names to install from this authority, the >> PM supports install of the latest package so only the package name is >> required at present, do we want/ need to support full fmri's here?? > > Yes, I believe full FMRIs should be supported. What delimiter are you > going to use? It should be a character that isn't allowed in FMRIs > (i.e. you can't use a ',' or ':', etc.). What do you suggest as a delimiter? > > What happens if one of the pkg_names provided isn't valid? The GUI handles the install of the packages as normal and would catch any errors such as invalid pkg_name. > >> Optional <-- Only additional field we need at present > Just a line wrap indicating that pkg_names should be Optional > What's this for? > >> Any thoughts? > > I'd prefer to see this information output in a json format; if not, at > the very least, all of the authority specific fields should get > prefixed with "authority." and the remainder with "info." or something > to make it obvious what is what and to make extending the information > easier in the future. > > How does this functionality get handled security-wise? Since this > file essentially gives the ability to arbitrarily install unknown > software, I'm assuming that it will always prompt the user with full > information about what will happen if they accept. That was the plan if you are installing software from a new authority. If you are installing from an authority already registered on your system, the plan was to go straight into the install dialog, but I take your point. A simple confirmation dialog listing what is about to be done does make sense, with Proceed and Cancel buttons, so I'll introduce that into the prototype and see what xDesign think of the overall flow. > > I don't think that this logic should be implemented only in the gui > (not even for initial implementation); instead it needs to be > implemented as part of the api, and both the cli and gui should > support it. I could envision the install subcommand of the cli taking > an additional -i or --info option that would contain a URL or filepath > to a package information file. The gui would work the same. The GUI and CLI will handle this in different ways which is fine, the underlying authority addition and/or package install will continue to use the underlying API's (authority API's are not yet available). For instance when adding an authority we'd like to at least detect if its using https and give the user the option of specifying SSL key and Cert. When we bind the mimetype the result of clicking on a web link of this mimetype is for the file to be downloaded onto the users /tmp dir and the bound application to be launched with this file path. That is what we are currently handling and can have it require a -i or --info option. We where not planning on handling a URL though we could. > > Finally, I think it's too early to implement this, though I'm all for > planning and discussing it. My personal belief is that both the > authority/0 changes and the configuration file format changes need to > be in place first. MimeType support is part of the OpenSoalris.Next requirements for the IPS GUI and we'd like to get moving on it if at all possible. The authority/0 changes do not need to be in place for the mimetype handling, we just need to agree on the fields that will be supported. When the authority/0 support is in place we could then optionally use the origin_url to ping the server to get all the rest of the authority information. With regard to the configuration file format changes, what is the timescale for this? Again its easy for us to switch the processing of a ConfigParser style config file to a JSON based format when its available. > > Cheers, _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
