On 10/19/11 11:29 AM, Drew Fisher wrote:
On 10/19/11 11:57 AM, Karen Tung wrote:
Hi Drew,
lines 578-588, and 639-640. This is identical code to lines 248-256
and 293-294.
Since this is the logic to use an alternate repo, I think it might be
better to
point in functions that can be called. In the future, if further
setup is needed
to point to an alternate smf repo, it can just be added in 1 single
place.
The code only differs in the SVCCFG_REPOSITORY variable. In
configure_smf(), that value is set to a temporary file in /tmp. In
configure_gnome_caches() it's done in the "proper" place. I could
move all of these into its own function, but it doesn't buy us much in
my opinion. What do you think?
With our latest discussion on the IM channel, I no longer think a
function is needed.
If you make those smf_env_vars a global variable for this class, and set
them if the dictionary
is empty, and just change the SVCCFG_REPOSITORY to point to the "proper"
place when
you need to configure the GNOME stuff.
Another thought is that perhaps we can leave all those env variables
set after the
configure_smf() function, and not unset it until the whole checkpoint
is done.
Then, we won't have duplicate code either.
I'd rather not do it that way. I'd rather only have the SMF variables
set for what they're needed for. I don't want to run into unintended
results by having those variables set.
OK, agreed.
line 592: question: would it make sense to make the stderr_loglevel
to be "error"
so it is consistent with line 597 below?
I want to move the search for *desktop-cache* to .info so the user can
see that we're looking for them. If none are found, I want that
message to be at the .error level as it's an actual error.
huh? I am confused. When you use run(), and you don't specify
stdout_loglevel, it will
default to debug, right? The command to be executed is printed at the
stdout_loglevel,
not at the stderr_loglevel.
Thanks,
--Karen
-Drew
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
