On 08/20/09 07:22, Dave Miner wrote:
> 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.
OK, I checked and p5i files can apply to any repo that is reachable via
a pathname or URI.
I think I'm seeing the light now... The p5i file can with one name
(URI) specify a package and a repo. When you use the word "superset"
above (in your first reply) I now take that to mean that a single p5i
file can specify a group of packages from a single repo if desired, or
even different groups from different repos, all in the same file. This
is more versatile than only being able to specify a single package and repo.
A quick check at a repo through a browser shows that every package has
an associated repo. Seems safe to remove the type="pkg" and have IPS
packages specified through the p5i specification instead.
>>>> 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.
OK. I like this idea, but it may be a lot of work. I'll propose it to
the DDU team; if they are too busy, then option 4 can be a fallback.
I'll update the spec with all changes discussed over the last few days
and repost before tomorrow COB (to accommodate any comments which could
come in on the add_drv -n email).
thanks,
Jack
>
> Dave
>
