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?
>> 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).
Thanks,
Jack
>
> Dave
