Jiri Srain wrote:
"workflow_order" : string // to allow ordering, string for better extendibility Yeah, I can see developers embeding YCP code in this string later. What is extendibility here then?
=Wkf =WkfCSum (if not specified in content file) =WkfOrd What value does WkfOrd has? I still don't see YaST specific stuff being part of the pattern definition.
First implementation expects only integer value but later one could define any possible dependency (after:pattern:some-other-pattern etc.). The initial proposal wanted just integer value but using a string we could express dependencies and orders across other Add-Ons and Patterns. Klaus wanted this feature :) and it makes sense for future. I've selected "string" even for this initial implementation just not to disturb you when the format changes.
http://users.suse.cz/~locilka/PatternsAndAddOnsWithWorkflows/proposal-200 7- 06-04.txt I have one question, I imagine the use case, you have a mail-server pattern, and if it installed you want to start the mail-server workflow.
How are you going to know either to start the postfix cfg workflow or the sendmail one, or [insert any supplied community module here]
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.
First, only one of these packages can be installed, postfix or sendmail. Second, the one, who writes the client configuring the mail (use-case) needs to handle with both, either sendmail or postfix. Workflow doesn't solve such issues. Lukas