On 09/22/10 03:21 AM, Jan Damborsky wrote:
On 09/21/10 08:26 PM, Keith Mitchell wrote:
On 09/21/10 07:53 AM, Jan Damborsky wrote:
On 09/17/10 11:53 PM, Keith Mitchell wrote:
[...]
14.1.1: Currently, the text installer doesn't have a
language/locale screen, as the user is prompted for that
information during boot. I assume this screen would be skippable
dependent on such factors?
The idea here was that SCI locale screen would replace language
screen displayed during boot process.
How would one choose the language for the installer itself, in this
case?
Good point :-)
We might still need to bring up locale screen in the text installer,
since set of install languages might be smaller than set of
languages to be installed.
With GUI installer as an example, the installer is localized into 22
languages,
but it is possible to select from more than 60 languages for installed
system.
Is this a requirement for install time or could this configuration be
done post boot now that we have much better tools and pkging to handle this.
-Sanjay
14.1.4: This screen is skipped in the text installer case if there
is only one NIC available on the system - would this continue to be
true?
It makes sense. Unless Frank has objections, I am fine with that.
14.1.6: Is it safe to assume that this screen would be disabled
unless a second option for naming services (beyond DNS) is added?
That sounds reasonable. We need to consult with Frank UI design of
those screens.
There are provisions in the text installer UI flow for easily
skipping certain screens - they may not be the most elegant (this SCI
work will be a good chance for me to see about streamlining some
things in the UI flow...)
I see. I was not aware of that. This is good to know.
14.1.5, 14.1.7: Currently in the text installer, these 2 screens
are combined. One of the goals for our installers has been to keep
the number of screens to a minimum. In general, it seems the SCI
tool is increasing the number of screen. What's the user experience
impact of injecting additional screens in this manner?
I agree - the current proposal mimics UI of legacy sysid tools
and is very likely subject of change. Again, we need to involve
Frank in this :-)
Certainly. It also sounds like there's some flexibility in that it
will probably be acceptable to have more screens for the text
installer since that installer targets more advanced users who might
want more configuration options at install time.
Yep.
14.2.1: "SC module will support mechanisms for customizing set of
displayed screens based on specified running environment."
One of the things I dislike most about our current mechanism for
ICTs is how they make decisions based on environment (e.g.,
existence of .autoinstall file) rather than making those decisions
based on parameters passed in. I'd prefer not to see the SCI tool
go the same route, and rather, allow the application to *tell* the
SCI tool what it should do, rather than the SCI tool "guessing"
based on environment. To quote the "Zen of Python" (PEP 20) -
"Explicit is better than implicit."
I am in agreement with you on that, I didn't explain it correctly in
doc.
I wanted to say that SC module would provide mechanism for
customizing set of screens
to be displayed.
The decision which set of screens is to be presented should be made
outside
of SC module, or completely outside of SCI tool. SCI tool could
accept environment
type as command line parameter.
As an example, when launched from smf service, it could look like:
[...]
. /lib/svc/share/smf_include.sh
env_type="global_zone"
if smf_is_nonglobal_zone; then
if smf_configure_ip; then
env_type="non_global_zone_exclusive_ip"
else
env_type="non_global_zone_shared_ip"
fi
fi
/usr/sbin/system-config -t $env_type
[...]
Thanks for the explanation - that's definitely a much better method
of running it. I might like to see this taken a step further, though
- e.g.:
if smf_is_nonglobal_zone; then
if smf_configure_ip; then
/usr/sbin/system-config --zone --ip-config=yes
else
/usr/sbin/system-config --zone --ip-config=no
fi
else
/usr/sbin/system-config --all
fi
One caveat to all this: It sounds like a user will *never* run
/usr/sbin/system-config, is that correct (i.e., sysconfig will always
run via SMF or an installer)? If so, then your approach above, or one
similar to my suggestion, is the right way. But if a user might ever
execute system-config (perhaps for a reconfiguration case, if that's
not doable via SMF), then I think it might be more acceptable for the
system-config tool to make assumptions based on environment (so long
as that can be overridden for purposes such as testing/debugging).
This is a good point. I am not convinced that we can say for sure
there will not be such scenarios (user initiating invocation of
sysconfig tool).
Based on that I agree with you that it seems reasonable to have
sysconfig equipped with that logic (ability to identify the running
environment)
with possibility to overwrite that.
Thank you,
Jan
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
