Jack Schwartz wrote: > Hi Dave. > > On 08/18/09 06:49, Dave Miner wrote: >> Jack Schwartz wrote: >>> Hi Dave. >>> >>> Thank you for your comments. Responses inline. >>> >>> On 08/13/09 15:30, Dave Miner wrote: >>>> Jack Schwartz wrote: >>>>> Hi everyone. >>>>> >>>>> I haven't received any email comments on the spec. >>>>> Is the spec so good that no one had anything to say? :) >>>>> >>>>> Seriously, if you do have something to say, please let me know >>>>> ASAP. The spec is starting to be used. >>>>> >>>>> Note that the link has changed (email was sent about this). It is: >>>>> http://www.opensolaris.org/os/project/caiman/Driver_Update/du-func-spec.txt >>>>> >>>>> >>>>> >>>> >>>> In section 3.3, Stephen had suggested use of p5i format to specify >>>> IPS packages. Is there a reason this wasn't chosen? >>>> >>> I don't understand the question given the context. The context is >>> that the manifest needs to differentiate IPS vs SVR4 vs DUimage type >>> packages. I interpreted Stephen's email to mean "Don't use the term >>> IPS to specify IPS packages, and so I changed all references to >>> "pkg(5)" or "pkg". AI will read the "add_drivers" entries in the >>> manifest to know which packages are needed to install, in much the >>> same way that AI reads the manifest to get the list of packages to >>> install or that DC reads the package list it needs to build an image. >>> >>> If there is more that I'm not getting here, please clarify. >> >> Stephen's message was perhaps a little subtle, but I believe there was >> a suggesting lurking there to use a p5i link specification (or p5c, >> which will be the on-disk format, once it's built), rather than >> separate type, name, location as you have specified. This is >> something we'll need to be supporting in the AI and DC as well. > OK. So right now (for context) we have this: > > <bundle type="pkg", name="SUNWraiddev", location="http://myrepo"/> > > We could add something like this: > > <bundle type="p5i", name="SUNWraiddev.p5i"/> > > where the p5i file would contain the package and repo. I'll update the > spec with this; if you had something else in mind please let me know. >
I believe that the p5i should be in lieu of, not addition to, the "pkg" type you proposed, as it's a proper superset that will be supported by any current release of pkg, both the client and server. I would suggest that it's more properly: <bundle type="p5i", URI="<file or http URL here>"/> > As for p5c files, they are not yet documented and are not completed yet > AFAIK. I'd like to defer p5c work as an RFE for later. Yes, that was meant as a later. >>>> 5.2.1: Why not provide a selectable option in AI to have more >>>> aggressive, "anything goes", automatic installation? I'm >>>> unconvinced of the "likely to be interactive" assertion here. >>> My first response to this was "sure, why not". But then when I >>> thought about it, it opens many cans of worms. >>> >>> Right now, the scope is doable. The kind of pkg we say we'll process >>> is represented in the database by just its name. We know what that >>> name represents and how to process it. >>> >>> If we open up to http URLs we don't know how to navigate them, as >>> they are all different; there can be anything in a webpage. Since >>> there is the possibility that webpage will be interactive, we have to >>> assume that it will be as the worst case scenario; how do we process >>> an interactive webpage from a non-interactive tool? Or, maybe you >>> know how to tell whether a URL is interactive or not? If so, please >>> let me know. >>> >>> If we open up to ftp, that could be a file or a directory; if a >>> file, we don't know what kind of package that file represents. Could >>> we figure it out? Maybe, but the scope broadens greatly and we >>> already have a lot to do. >>> >>> There may be other formats we could accommodate as well (the DDU >>> database doesn't have other kinds right now) but again the scope is >>> not feasible IMO. >> I think you're making this too hard. Why would we not just require >> that the link be directly to an installable software bundle in one of >> the formats supported? > We discussed this today and decided that it was sufficient extra work > without sufficient benefit, to defer it until later. I'll file an RFE. I'd like to hear more about the tradeoffs in that discussion, I guess, as I sense from other comments that it is desired. It seems at the least you should be taking the requirement to make all URL's only be non-interactive for this case so that it can be implemented easily later. Dave
