Michael Andres wrote:
On Fri, Jun 22, Lukas Ocilka wrote:
On Friday 22 June 2007 15:54:27 Lukas Ocilka wrote:
Workflow for packages was never wanted and might be added later. Currently we support only Add-Ons Products and Patterns. So we do it in a hacky way resolvable kind per resolvable kind. What will you do when we have to support it with packages? It's actually not a "hacky" way, but the "way of minimal changes". What I wanted was a minimal change to libzypp and pkg-bindings just to have
Duncan Mac-Vicar Prett wrote: the wanted feature.
IMO "No": it's not the "way of minimal changes"
It's the way of minimal changes in libzypp. When I asked some libzypp developers how much work they had, they replied that I couldn't expect more changes than a minor ones because major parts of code were being rewritten.
You already have the workflow xml, the workflow is extensible, the only thing left is:
When to execute which workflow?
Workflows can be added and they can be, of course, removed later. Imagine five Add-On products with their own workflows which you add one by one and then remove the first, the third and the fifth ones. You can play with going back and forth through the installation from "Add-Ons" to "Installation Proposal" - it means that there is no "one particular" place when workflows are just merged. To present even a worse case: Add-On workflow is merged immediately on leaving the Add-Ons dialog, some workflow changes can be done just after that dialog (removing timezone, adding some other dialogs etc.). This all is already solved by a WorkflowManager module that stores the main and additional workflows and merges the additional workflows one by one from scratch when some workflow is removed. One of the main solutions of $this feature is the unification with Add-Ons and their workflows. Please, read the article mentioned in this thread first. There is only a little difference between Add-On and Pattern workflows.
- Provide an index file mapping 'workflow->selection'.
- Instead of looping through the patterns to be installed, and asking them for an associated workflow,
loop through the patterns to be installed, and look whether they appear in your workflow index.
Libzypp shouldn't decide where, when and how to merge a pattern workflow WorkflowManager needs to merge it. Partly because not only installation, but also "add-on" and "sw_single" on a running system should be supported. And sw_single, for instance, has no workflow.
That way, neither Pattern metadata generation (abuild), nor Pattern parsing (zypp), nor the cache database (zypp), are affected.
I can't see the point here. Patterns needs to be generated anyway, Pattern workflow as well. Add-On and Pattern workflows have the very same format as control.xml file - they can change every single feature that control.xml defines. Cache database is affected only when some workflow is added - not changed. Workflow files are downloaded using Pkg::SourceProvide(Optional)File().
And you can extend your feature anytime, without affecting abuild/zypp.
I've asked for use-cases many times, there is no single use-case even for this feature, I don't see any reason for extending it in a near future (but ordering).
Yes, you need one parser for your index file, but thas's IMO cheaper than the current plan.
Actually, I could really omit using libzypp and create a file that links patterns with a specific workflow and its presentation order ... but what's the difference between let's say pattern_order (useful for packagemenager) and pattern_workflow_order (for workflowmanager)? Moreover, the file would need to be cached because of CD/DVD-based Add-Ons, additionally a refresh in a WorkflowManager would need to be called for online repos. Where is the advantage of doing things twice when we have library, that already doe's the needed task? If it is too much work, I can, of course hack everything in YCP layer which is pretty slower than libzypp. Short story: One or two weeks ago, a new QA member came to you office and asked how to parse the rpm's command output effectively, how to find out am rpms that contain all the needed libraries etc. He just wanted to write libzypp solver in Bash. Isn't that funny? L. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org