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? > .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. > repository_nickname: Optional What if the nickname conflicts with an existing one? > 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? > 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 happens if one of the pkg_names provided isn't valid? > Optional <-- Only additional field we need at present 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. 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. 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. Cheers, -- Shawn Walker [1] http://filext.com/file-extension/pkg [2] http://filext.com/file-extension/ips _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
