Hi Shawn.
On 07/30/09 11:19, Shawn Walker wrote:
> Dave Miner wrote:
>> Shawn Walker wrote:
>>> Dave Miner wrote:
>>>> Jack Schwartz wrote:
>>>>> Hi everyone.
>>>>>
>>>>> The Driver Update Use Case document has been uploaded to:
>>>>> http://www.opensolaris.org/os/project/caiman/Driver_Update/use-case-summary.latest.txt
>>>>>
>>>>>
>>>>>
>>>>> This describes how Driver Update additions would look from a user
>>>>> point of view, for live CD GUI, text installer, and AI.
>>>>>
>>>>> This has already gone through a few iterations with Frank and
>>>>> others, and should be fairly complete, so it should be pretty solid.
>>>>>
>>>>> Please send comments or questions over the next couple of days, if
>>>>> any.
>>>>>
>>>> The solution described in use case 1 is rather un-GUI-like. I'd
>>>> suggest discussing this with Frank, and considering more of a
>>>> wizard-style design. Or perhaps that's what you're trying to
>>>> describe, and the terminology just doesn't jibe.
>>>>
>>>> The solution in use case 3 tries to infer format based on the
>>>> attributes specified, and misses existing and future options. For
>>>> example, it's possible to install SVR4 packages from an http URL,
>>>> and IPS will have an on-disk format in the future. I strongly
>>>> recommend making declaration of package type explicit, if that's
>>>> necessary, or have it automatically resolved by your solution based
>>>> on a recognition of the location's format (which may be relatively
>>>> simple). You mention a compatibility requirement for DU packages,
>>>> but I'm unclear how you expect to make that determination.
>>>
>>> I also question the support of SVR4 packages given that many of them
>>> no longer install correctly on OpenSolaris 200x releases because of
>>> bad assumptions they make (such as the existence of /usr/ucb/
>>> commands).
>>>
>>> Is there going to be special logic in place that analyzes and
>>> transform the SVR4 package content into an IPS package and then uses
>>> IPS to install it?
>>>
>>
>> That seems, um, difficult.
>
> I know, that's why I'm questioning the support of SVR4 packages.
>
> So, if SVR4 driver packages are going to be officially supported, is
> the team going to have a nice big warning that says 'WARNING:
> installation of SVR4 packages may or may not work correctly'? :)
>
> I'm only half-joking here.
>
> I've personally encountered more than a few SVR4 packages that do not
> install correctly, or fail during install because of the assumptions
> they make when you attempt to install them on an OpenSolaris 200x
> system. The one I can think of at the moment if the Marvell Yukon
> driver.
>
>>> SVR4 package support is fairly minimal at the moment, and is
>>> deprecated or obsolete (not sure of the 'official' terminology).
>>> Why even support it at this point?
>>>
>>
>> Because that's the format some drivers are available in. Yes, we
>> have all sorts of ISV/IHV engineering teams fired up to get them
>> converted to IPS, but I'm favoring adoption over purity.
Yes, it will be easier for users to get started with OpenSolaris if
their rare controller card's driver can be loaded without them having to
find an IPS-packaged version of it.
If their package behaves and has only new files and doesn't overwrite
system files, I believe there should be no problems.
>
> I figured as much, but it isn't a panacea. Is there going to be an
> escape hatch for users stuck with broken SVR4 packages?
We can check each file in the package being added, and display a warning
if that file already exists on the system. Does this sound reasonable?
Thanks,
Jack
