Luke Kanies schrieb: > On Jun 5, 2009, at 7:53 AM, Stephan Gorget wrote: > >> Luke Kanies a écrit : >>> On May 29, 2009, at 8:06 AM, Stephan Gorget wrote: >>>> I rewrote the patch to match what you said, but package installation >>>> doesn't respect ordering now because I no longer use >>>> resource.evaluate(), I haven't found a function that determines if >>>> the >>>> dependency graph is satisfied, the allow_processing?() function, >>>> which >>>> based on the name seems to be the right one to use, doesn't do that. >>> Ordering shouldn't really matter here -- packages will only ever be >>> installed too early, rather than too late. >> From my point of view ordering matters, you can have a require for a >> specific package, for example package1 requires file1 and file1 >> requires >> package2, so there is no way you could combine the installation of >> package1 and package2 without breaking the dependency graph. > > The point, though, is that you will very rarely find a case where > installing a package too soon is much of a problem. Compare this to, > say, services, where attempting to start a service before its > dependencies have been installed is a real problem. > > With packages (at least with yum and apt), any dependencies of the > package itself will be automatically installed, too, so it's no problem. > > Really, I think the only resource types that could even be combineable > are those that don't have significant ordering concerns.
I don't know how much code/effort it would be, but when the dependency graph is toposorted, it is (mathematically) possible to find groups of packages with non-conflicting dependencies. Essentially by going through all packages and selecting those which are only connected by direct dependencies (or not connected at all). These groups can then be installed together without violating the configuration's constraints. Implementing the grouping in the dependency graph could make it easier for all types/providers to provide grouping functionality. Most providers having a flush method (e.g. parsedfile) probably could profit from this. Regards, DavidS -- dasz.at OG Tel: +43 (0)664 2602670 Web: http://dasz.at Klosterneuburg UID: ATU64260999 FB-Nr.: FN 309285 g FB-Gericht: LG Korneuburg --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
