Hi everyone.
I agree with Sarah.
The point of Driver Update is to make it easier to install drivers in
the installation environment. Why go through all of that effort to
implement Driver Update, and then make it harder to, say, configure the
network that
Driver Update needs to use to get the drivers?
Even if it is admins who install systems and use the DDU, why make it
harder than it has to be?
Thanks,
Jack
On 03/ 8/10 06:30 AM, Sarah Jelinek wrote:
>
>
> On 03/ 7/10 11:30 PM, Alok Aggarwal wrote:
>> Hi Jan,
>>
>> On Mar 4, 2010, at 1:11 AM, Jan Damborsky wrote:
>>
>>> Hi Alok,
>>>
>>> thank you very much for bringing this point up.
>>> Please see my comments below.
>>>
>>> Jan
>>>
>>>
>>> On 03/ 3/10 01:04 AM, Alok Aggarwal wrote:
>>>> Hi Jan,
>>>>
>>>> On Tue, 23 Feb 2010, Jan Damborsky wrote:
>>>>
>>>>> Hi Sarah,
>>>>>
>>>>> thank you for looking at this !
>>>>>
>>>>> I have captured the outcome on System Configuration Project pages
>>>>> (in section Automated Installer):
>>>>>
>>>>> http://hub.opensolaris.org/bin/view/Project+caiman/System+Configuration+Project
>>>>>
>>>>>
>>>>>
>>>>
>>>> I just looked system configuration proposal and have
>>>> a question.
>>>>
>>>> The proposal mentions that system configuration will
>>>> cover interactive installers as well. Some of those interactive
>>>> installers might have a requirement to have the user
>>>> selected system configuration be applied not only to
>>>> the installed system but to the installation environment
>>>> as well. For example, the installer might allow the user to specify a
>>>> network configuration that should be applied
>>>> not only to the installed system but to take effect during the
>>>> installation too.
>>>>
>>>> Is this something that is going to be supported by the
>>>> system config proposal?
>>>
>>> In general, that requirement falls under Sysconfig project.
>>> We haven't made final decision yet what approach is to be taken
>>> as far as Interactive installers are concerned - Automated Installer
>>> scenario is currently being worked on.
>>>
>>> However, since the general intent here is to avoid design and
>>> code duplication, we need to keep other scenarios in mind
>>> when particular decision with respect to design is made.
>>>
>>> For this effort, I think it would be useful if we try to identify
>>> requirements and scenarios where other installers and
>>> System Configuration project will interact.
>>>
>>> With respect to the case you mentioned above, in order to better
>>> understand the scope, could you please elaborate more on
>>> the problem(s) that requirement is expected to solve ?
>>> What kind of installers (GUI, text) and transfer methods (CPIO, IPS)
>>> are in scope ?
>>
>> I've since talked with Dave and couple of others about system
>> configuration within the installation environment. The thought
>> is that we don't want the installers to have to deal with this in
>> the install environment. And, whatever system configuration
>> we do allow, we allow it only on the install target.
>>
>
> Why wouldn't we want installers to be able to say, configure the
> network in the install environment with a static ip? Some customers
> don't have or don't want to use DHCP.
>
> What is it the installers would have to deal with, with respect to
> this, other than utilizing the system configuration utility we provide
> to do this? What issues do we see making system configuration apply in
> the installation environment? I am not sure we should just say at this
> point it isn't required.
>
> thanks,
> sarah
> ****
>
>> With that, I'd like to retract this requirement with respect to
>> the interactive installers.
>>
>>> Are there other requirements coming from interactive installers
>>> which might fall under sysconfig project ?
>>
>> Nothing beyond what is already covered in the proposal.
>>
>> Thanks,
>> Alok
>>
>>
>>
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
