Ticket #824 (closed enhancement: wontfix)

Opened 12 years ago

Last modified 10 years ago

Add mechanism to check for the absence of a package

Reported by: Bruce Bush <[email protected]…> Owned by: desai
Priority: minor Milestone: Bcfg2 1.3.0 Release
Component: bcfg2-client Version: 1.0
Keywords: Cc:


The Package and BoundPackage? statements confirm and the status of an installed package. It would be useful to have a 'RemovePackage?' tag that would check to make sure a package is NOT present and remove it if it is present. 'bcfg2 -r all' lacks granularity. The 'RemovePackage?' statement would be helpful to users implementing bcfg2 who do not have all their software managed yet, but would like to have a mechanism to selectively remove software packages.


Change History

comment:1 Changed 12 years ago by solj

  • Milestone changed from Bcfg2 1.1.0 Release to Bcfg2 1.2.0 Release

comment:2 Changed 11 years ago by solj

  • Milestone changed from Bcfg2 1.2.0 Release to Bcfg2 1.3.0 Release

This shouldn't be difficult to add. However, I don't think it'll be done by 1.2.0. On a side note, wouldn't this (potentially) add a lot of size to your configuration? I mean, once the package is removed, the entry is essentially useless. It seems like it'd be cleaner to use bcfg2 + pdsh or something to simply do a one-time removal.

comment:3 Changed 10 years ago by

I find myself agreeing with Sol on this one, but I don't think this would be easy to add, and it could add a lot of complexity to configurations.

Consider a configuration like this:

<Package name="bcfg2-server"/> <Package name="python-genshi" type="remove"/>

bcfg2-server depends on python-genshi, so this isn't possible. It would result in a bogus configuration being pushed to the client -- it would contain both python-genshi as a package to install and to remove -- and processing the python-genshi removal would force removal of bcfg2-server, which would force reinstallation of bcfg2-server. It'd be a mess.

We could mitigate the issues somewhat by filtering removed packages out of the list of packages to install, but you'd still have the issues with infinite install-uninstall loops on the client. This is not an issue with <Path type='nonexistent'/> because you'd have to specify both Paths in your configuration (unlike Packages, dependencies of which are automatically added by the plugin) and that's invalid. Basically, the issue is that Packages, unlike Paths, are not atomic -- you can't separate one package out from all the others, and that puts a lot of burden on the user to make sure their package removal is sane.

I agree that this problem is better solved by something like pdsh, and I recommend closing this as wontfix.

comment:4 Changed 10 years ago by

  • Status changed from new to closed
  • Resolution set to wontfix

WARNING! You need to establish a session before you can create or edit tickets. Otherwise the ticket will get treated as spam.


Add a comment

Modify Ticket

Change Properties
<Author field>
as closed
The resolution will be deleted. Next status will be 'reopened'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.