Bug 386633

(In reply to comment #0 from Lukas Ocilka)

> [Interpreter] clients/online_update.ycp:313 Calling YaST client online_update
> (arguments: [$["enable_back":true, "enable_next":true]])
> CommandLine.ycp:1215 Command line interface started (why?)

This is usual every time you call client that has CLI support. But it should not hurt if the arguments would be correct.

Daniel, why is 'yast2 online-update called with the map argument ($["enable_back":true, "enable_next":true]) ? It doesn't seem to have any sense.

(Or, Ladislav, maybe such argument should be correctly discarded by CommandLine.ycp?)

> Finally, online update script fails and UI returns that calling online-update
> has failed because client returned invalid data.
> clients/online_update.ycp:313 Can't convert value '1' to type 'symbol'

online_update.ycp returns integer, not symbol, this is intentional. The caller of this client should not expect symbol.

> > Finally, online update script fails and UI returns that calling online-update
> > has failed because client returned invalid data.
> > clients/online_update.ycp:313 Can't convert value '1' to type 'symbol'
> 
> online_update.ycp returns integer, not symbol, this is intentional. The caller
> of this client should not expect symbol.

So it seems piwo needs some handler script. ProductControl just expects and will expect symbol because using this symbol is vitally important to control the dialog flow `back, `next, `abort, `cancel, `auto.

The problem is here:

2008-05-05 11:58:59 <1> gizo(9480) [Interpreter] clients/online_update.ycp:313
Calling YaST client online_update (arguments: [$
["enable_back":true, "enable_next":true]])

The CommandLine module thinks that the command line mode is active because
there were passed 2 arguments. Run time clients should not be used by this way.

online_update.ycp already checks for some parameters (like .simple_mode) which do not start the command line mode. There could be one more exception.

But think the right solution is to have an installation client and a runtime client (GUI/CLI).

> (In reply to comment #3 from Ladislav Slezak)
>
> The CommandLine module thinks that the command line mode is active because
> there were passed 2 arguments. Run time clients should not be used by this way.
> 
> online_update.ycp already checks for some parameters (like .simple_mode) which
> do not start the command line mode. There could be one more exception.

Yes, the map parameter could be handled in the online_update.ycp as another exception, but not the return value.


> But think the right solution is to have an installation client and a runtime
> client (GUI/CLI).


Well, there is an installation client (inst_you) and runtime client (online_update), and inst_you should be used in the sequence. But it was designed for installation and I have no idea if it would work on installed system.

IMHO the "piwo" concept of using the part of control file and calling the files from installation sequence is wrong. Why can't you use the usual Sequencer as in all other modules used on installed system?

(In reply to comment #4 from Jiří­ Suchomel)
> IMHO the "piwo" concept of using the part of control file and calling the files
> from installation sequence is wrong. Why can't you use the usual Sequencer as
> in all other modules used on installed system?

I wouldn't say that it is wrong. Sequences has been designed to call dialogs, functions. Piwo design is really workflow-based, so using ProductControl sounds like a good idea (and/or WorkflowManager).

Hm, but with proper clients.
We have a Sequencer.ycp module for workflow-based modules.

So, what are the solutions:

1. rewrite piwo.ycp to use Sequencer.ycp (I would prefer this, but it is some work of course)

2. use a small wrapper (register_online_update), that would be defined in your piwo.xml sequence and which only task would be to
   a) call 'online_update' client without any argument
   b) take care of its return value (it can be `abort symbol or integer, which means: 0 for OK and -42 when client needs to be restarted)

   As an alternative, it could define some new argument for online_update, which would force returning symbol.

3. use inst_you instead of online_update. I would not recommend this, since inst_you  expect the installation state and it may require something we do not see now.

4. call 'online_update' directly from piwo.ycp when the previous sequence ends with `next/`finish/`ok

*** Bug 386408 has been marked as a duplicate of this bug. ***

The problem with above solutions is that YaST is not get restarted when Online Update installs a patch requiring restart. For this, 'yast2 online-update' should not be started from another YaST module. Can't you just call if from the applet when the previous sequence is successful?

(In reply to comment #9 from Jiri Suchomel)
> Can't you just call if from the
> applet when the previous sequence is successful?

Regarding the possible solutions this idea sounds quiet reasonable. I will clarify that. Thanks.

The updater applet is checking for updates anyway after it called piwo, so I can safely remove online_update from the workflow.

Thanks, that looks like a best solution!

This is an autogenerated message for OBS integration:
This bug (386633) was mentioned in
https://build.opensuse.org/request/show/844234 Factory / yast2-registration