On Fri, Jun 22, Jiri Srain wrote:
Dne p??tek 22 ??erven 2007 14:30 Michael Andres napsal(a):
On Fri, Jun 22, Jiri Srain wrote:
Hi!
In order to allow workflows bound to patterns we need to extend the pattern definition on the media as well as the database and in-memory representation of a pattern. We need following tags:
"workflow_file" : string // file describing the workflow on the media "workflow_file_checksum" : the same as other checksums "workflow_order" : string // to allow ordering, string for better extendibility
(the names can be adapted to fit attribute naming schema)
The suggestions for the SuSEtags metadata format are
=Wkf =WkfCSum (if not specified in content file) =WkfOrd
ZYPP is not required to process this data anyhow (maybe except the checksum?), all that's needed is to deliver the data to YaST. The update of package bindings will be trivial.
- But why putting this into the pattern definition? Why not one (separate) file that maps pattern<->workflow, but spreading it across several locations?
It is an option as well. But thhere must be a binding between a pattern and itw workflow and it must be possible to define it in all our supported metadata formats. That's the only requirement.
- workflow_file and workflow_file_checksum must appear in the content file anyway.
Otherwise we had to parse all the patterns to see whether a workflow file changed and we must refresh. And changing the workflow would require reloading the pattern (because of the changed checksum)
Right, but if a new workflow is added, you have to modify the pattern in the database anyway, since the workflow is a part of a pattern the very same way as packages the pattern should drag in.
Only for YaST. Nobody else (e.g. zypper) associates such a workflow with the installation of a pattern. ( BTW: why do you limit the workflow extensions to be used with patterns only? Installation of a pattern is just the trigger to execute the workflow. So why not executing a workflow when a certain Package gets installed? Or a certain Language? Or something is updated, or gets deleted, or whatever event you can imagine... ) This would result in a kind of workflow index, that lists the available workflow, and defines the events that trigger it's execution. Installation of a certain patter could be such an event. Installation of a single package, or a language, or product, could be an event as well. Or even distinguish between install/update/delete. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org