Mailinglist Archive: zypp-devel (116 mails)

[Lukas Ocilka <lukas.ocilka@xxxxxxx>]

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