On Sep 11, 2007, at 9:40 AM, Daniel Dehennin wrote: > The first thing I want is to be able to use list variable, as an and > for class definition: > > control: > feature = ( pkg1:pkg2:pkg3 ) > > packages: > $(feature) action=install elsedefine=featureNotInstalled > > I think ExpandVariable should occur in InstallPackage, as I understand > this does not expand list so we get the string "pkg1:pkg2:pkg3" as > ptr->name in CheckPackages. > > This may be the place to expand the list and define or elsedefine > based on an and of packages: if one is missing/wrong version, > elsedefine take place. > > At first I thought that version is not accurate with list variable > package but a feature can be composed of 3 parts which are optionnal > and versionned in the same way.
I agree that this might be a worthy goal, but I am looking at the code and I suspect that this is harder than you might imagine. You'd need to break the list out at the top of the function and iterate through the list. I mean, it's easy to implement because it would be just another loop inside the current loop. However, that syntax is very much less flexible because all three packages would need to be the exact same version. In short, even if you do make it work it is only relevant to install, and upgrade or remove are impossible unless all three are the same version. Yeah, the more I think about it the more I think that this syntax has such very limited use (ie *never* for any standard packages -- only for locally built packages where versions can be kept in sync?) that I can't figure out why it has value to you enough to spend time writing the patch. That said, it should be easy to write. Add an interior loop in do.c CheckPackages() that only loops once for non-list variables. Add a flag to determine if one of the packages failed so that you can break out of the interior loop and skip checking the remainder. > I agree. I was looking for creating a module for dpkg management, > based on libapt-pkg to avoid the use of external processes but it's > C++. *shrug* You could do it and submit it to Mark to see if he wants to include it. I'm not sure that he would see value in putting pkmgr- specific code into cfengine. (I mean lots of it, rather than just a routine which invokes the pkgmgr) > Maybe this discussion is better somewhere else than in private ? I ask > it because there is not official dev mailing-list. I've CCed bug-cfengine which appears to be the dev list in practice. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 _______________________________________________ Bug-cfengine mailing list [email protected] https://cfengine.org/mailman/listinfo/bug-cfengine
