Custom Query (894 matches)
Results (142 - 144 of 894)
Ticket | Owner | Reporter | Resolution | Summary |
---|---|---|---|---|
#645 | desai | [email protected]… | worksforme | Default attributes for Package elements |
Description |
The recent addition of version="any" support for the SYSV/Blast/APT drivers has made package management a bit easier in some cases. However, it still requires a list of packages in Pkgmgr files, just to specify each package's version and type; which seems a little silly, since they're all the same. The attached patch allows specfying something like: <PackageList priority="0" type="deb"> <Group name="lenny"> <PackageDefault version="any"/> </Group> </PackageList> Which means that for all clients in group "lenny", <Package> elements default to the attributes in the <PackageDefault> element above, if an explicit <Package> element for a specific package doesn't exist. It also allows for specifying a match="regex" attribute, which makes the <PackageDefault> element only apply to packages that match that particular regex. This can be useful, for example, on Solaris boxes that use both SYSV and Blast packages. Providing <PackageDefault> entries for both package types could look something like this: <PackageList priority="0" type="sysv"> <Group name="sun-solaris"> <PackageDefault version="any"/> </Group> </PackageList> (or possibly match="SUNW.*"), and in a diferent Pkgmgr file: <PackageList priority="1" type="blast"> <Group name="sun-solaris"> <PackageDefault match="CSW.*" version="any"/> </Group> </PackageList> Which would default to blast packages for package names beginning with CSW, and sysv packages otherwise. I'm unsure of the elegance of part of this implementation (it probably breaks if a <PackageDefault> element is given a name, or if two <PackageDefault> elements are in one Pkgmgr file), but I wasn't sure what to do better. It should be trivial to make this work with Rules, or any other PrioDir-derived plugin. This patch is also against 0.9.5.7 (with a few other local patches). I don't know how difficult it is to port it to newer versions, but is it possible to work this into the 1.0 release? I'll be posting about this on the bcfg-dev list shortly, for perhaps a wider discussion on the interface of this. |
|||
#471 | desai | [email protected]… | invalid | test case |
#440 | desai | [email protected]… | fixed | bashism in init script |
Description |
in debian/bcfg2.init, there is a line: [ "$BCFG2_ENABLED" == "0" -o "$BCFG2_INIT" == 0 ] && exit 0 this should be: [ "$BCFG2_ENABLED" = "0" -o "$BCFG2_INIT" = 0 ] && exit 0 Looking forward to using bcfg2 now :-) |