Jack Schwartz wrote: > Hi Dave. > > On 08/19/09 13:55, Dave Miner wrote: >> 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>"/> > I agree with your definition of a p5i manifest element, but I believe my > type="pkg" definition has functionality which the p5i definition cannot > fulfill and would like to keep them both, side by side. So I'll explain > my reasoning and ask the questions for clarification: > > 1) The type="pkg" definition allows for a blank location, in which case > the "repo path" (which could have multiple repos) specified for the > packages added during install proper would be used. Can multiple repos > be specified in a p5i file? > > 2) I think p5i is specific to a net repo (just as p5c is specific to > disk repos). Is this correct? By contrast, the type="pkg" definition > won't care where the repo is or medium it is on; it should just work. > Why make the user distinguish the type of medium the repo is on with > "p5i", when type="pkg" can handle any kind of repo? Or is there > something I am missing?
I believe you should discuss the above questions with one of the IPS developers if the docs available don't answer them. >>> 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. > There are a few options. If doable, I think the last option is best. > > 1) Keep the format of the database the same. Figure out what the > non-Solaris package entries represent. What do their links (http, ftp, > whatever) point to (directories, downloadable files, webpages which need > to be navigated). Download only where it makes sense. > > Doing this is what we discussed at the meeting as being too hard. > > 2) Don't allow automatic install of third party drivers. > > 3) Require that third party driver links be only pointers to > downloadable files. I would see this as a regression from what the > database offers currently. Right now, a properly equipped DDU could > display the information in the database, to point the user to the > location for a manual download. The spec requests this. To require > third party drivers to be only pointers to downloadable files would be > to strip out this useful information for drivers available only at > navigatable webpages. > > 4) Here's a new option... The database could be changed to distinguish, > say, http links which go to webpages requiring navigation, vs http links > which go to downloadable files. This way, the DDU can know which links > it can download from, and which ones it can only display in a "manually > download" message. > > Right now the database has categories of: > S - solaris driver (names in these entries are pkg(5) names - only this > category can be installed by the DDU currently AFAIK) > T - third party driver > O - OpenSolaris driver (from opensolaris projects, webpages given, not > package names) > > I suggest splitting the T and O categories into separate ones for links > pointing to installable files, or not. All S category items are > installable via pkg(1). > Another option that I think is possibly better is to enhance the database to allow specification of both a direct link and an informational link. The latter is appropriate for interactive uses, but not automatic ones. Dave
