On 07/ 6/10 11:54 PM, Keith Mitchell wrote:
On 07/ 6/10 07:05 AM, Jan Damborsky wrote:
Hi Keith,
thank you very much for looking into this.
Please see my response in line.
Jan
On 06/29/10 12:47 AM, Keith Mitchell wrote:
Hi Jan,
Like Joe, I couldn't find very much wrong with these changes.
Nevertheless, I can always nit at something and I've got a few
questions as well.
install-finish:
Based on the webrev and bug comments, I don't quite understand the
strategy going forward. It looks like for liveCD and Text Install,
the SC profile is copied over; for AI no keyboard setting is done -
does this mean that on first boot after an AI install, the user is
prompted for keyboard choice? Or is the setting applied elsewhere?
As far as AI is concerned, it originally did not support configuring
keyboard layout -
it was hardcoded to US-English (see bug 4585).
For AI, the overall strategy is to configure things via SC manifest
which is in form
of SMF profile. Since this mechanism is now available (push has
happened earlier today),
I have enhanced scope of these changes with AI related modifications.
They are merely about enhancing default AI manifest with default
configuration for
keymap SMF service - the updated webrev is available at [1].
Related bug:
4585 Automated Installer needs support for setting keyboard layout
from AI manifest
I think I understand now. In the AI case, the ICT
"apply_sysconfig_profile" takes care of applying the settings; for
interactive installers, the ICT "keyboard_layout" is still required
(for now).
Yes, that is correct.
ict.py:keyboard_layout():
The method for applying the sc_profile does not seem extensible in
this fashion. What happens if, before ICTs are removed as such, we
need to apply a different sc_profile change? I suggest a different
approach - during ICT.__init__, read the sc_template in (either as
an lxml.etree or a plain string). Modify the in-memory
representation during ICT execution, and then write the file to the
destination after all ICTs have completed (as a separate ICT
function perhaps). The following XPath expression would get the
appropriate location here, assuming the lxml.etree route:
layout_element =
sc_template_etree_object.xpath("//servi...@name='system/keymap']/instan...@name='default']/property_gro...@name='keymap']/propv...@name='layout']")[0]
#xpath returns a list, but there should only be one default instance
layout_element.set("value", layout)
Using etree/Xpath also means that the results will be more
consistent - consider what would happen if the sc_template had a
second "US-English" string somewhere in it. The parameter to the
Xpath call can, of course, be statically defined somewhere.
In general, I agree with your points and the proposed mechanism
is definitely not the final solution, but as I pointed out,
rather proof of concept and its scope is limited to configuring
keyboard layout and maybe hostname.
The current plan is that this mechanism will be replaced by XML
compliant generator of SC profile as part of 'interactive SC tool'
effort (which I believe we will cooperate on soon :-)
Please let me know if it addressed your concerns.
(I admit I got sidetracked by xpath... though it was fun to delve into
that for a moment)
I'm still concerned with how "hostname" would have to be handled,
since it will have to write to the same destination file. If it
follows the same structure, it will clobber the previously written
keyboard layout, since it would end up reading the "sc_profile_src"
from the sc_template.
Right.
Perhaps the simplest solution would be to rename the "keyboard_layout"
ICT to "generate_sc_profile", and then simply have any interim
SC-related changes for interactive installers get dropped in there.
That would at least make it easy to manage until the final solution
comes along.
Done. I have updated webrev accordingly:
http://cr.opensolaris.org/~dambi/bug-15678-4585/
Thank you,
Jan
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
