Mailinglist Archive: zypp-devel (116 mails)

[Lukas Ocilka <lukas.ocilka@xxxxxxx>]

Duncan Mac-Vicar Prett wrote:
> On Friday 22 June 2007 15:23:11 Jiri Srain wrote:
>> The workflow must be defined the way that it will properly run which wizard
>> is needed.  It can check which dialogs to run depending on packages which
>> are installed. In your case, if the pattern contains both sendmail and
>> postfix, it should ask user in the first step. Obviously if we ship
>> sendmail and postfix, user selects this pattern but installs eg. qmail, the
>> pattern workflow cannot take care of it.
> 
> That exactly my point. How are you going to know which packages a 
> pattern "contains"?. Only the solver knows.

I'm afraid I didn't explain it in an understandable way.

* Installation (as well as yast2-addon, sw_single...) will handle
  whether some patterns were selected to be installed.
* Installation has own base-workflow, other workflows can be added
  by Add-On products and/or Patterns.
* Installation doesn't handle the pattern-workflows, doesn't operate
  with information which packages are selected and what to do with it.
  It just runs the client defined in workflow, that's all.

For instance, OES2 has own installation workflow - the one that extends
the default SLES 10 SP1 workflow. Installation doesn't case what OES2's
additional clients do, it just runs them.

> You would need to do a 2nd stage kind of solving (looking for package names 
> matching) after the solver runs (and you can still not be sure which pattern 
> is the guilty one that selected the package. ),  So you are putting more and 
> more logic in the UI and breaking all the improvements from the old 
> selections to patterns.
> 
> So as usual we are abusing the solver, the language and the UI/Controller, 
> because at the end a workflow has _nothing_ to do with the pattern itself but 
> with the pattern installation result (specially individual software)

Workflow is assigned to pattern, such as Add-On product can have its own
workflow as well.

> The correct way to do this would be using dependencies, so if a certain 
> package gets installed, a worflow or special trigger file (part of the module 
> package) is also grabed and installed. The installation detects this and 
> starts the workflow. This only works if the workflow is run after the 
> software is installed, but I guess you can't configure the software if it is 
> not installed.

Workflow for packages was never wanted and might be added later.
Currently we support only Add-Ons Products and Patterns.

L.