Custom Query (894 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


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 :-)

Note: See TracQuery for help on using queries.