Merge lp:~gandelman-a/charm-helpers/filter_req_packages into lp:charm-helpers
Status: | Merged |
---|---|
Merged at revision: | 25 |
Proposed branch: | lp:~gandelman-a/charm-helpers/filter_req_packages |
Merge into: | lp:charm-helpers |
Diff against target: |
123 lines (+81/-0) 2 files modified
charmhelpers/core/host.py (+26/-0) tests/core/test_host.py (+55/-0) |
To merge this branch: | bzr merge lp:~gandelman-a/charm-helpers/filter_req_packages |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Matthew Wedgwood (community) | Approve | ||
James Page | Approve | ||
Adam Gandelman (community) | Needs Resubmitting | ||
Review via email:
|
Description of the change
We run into instances where we've deployed a charm and a week later trigger some relation event that calls 'apt-get install' In that weeks time, a newer package has been published to the Ubuntu archive, causing apt-get to block on local config changes. To help keep these types of hooks idempotent, it would be helpful to only attempt installation of packages that require it, eg:
CORE_PACKAGES = ['mysql', 'apache2']
apt_update()
apt_install(
Thought about adding a call to filter_
I think this is a good addition, but I have some (perhaps nitpicky) problems with it as-is:
1. The function name is a little opaque. "Required" is a little vague. Also, you're actually filtering the packages that aren't required. Perhaps filter_ installed_ packages would be ok?
2. The function assumes (by throwing an exception) that the package cache is up-to-date. It makes sense to me simply to filter the packages that are already installed, returning everything else. That way you could run 'apt-get update' later if an un-installed packaged required a new repo. This should still fit your use case, as an exception would be thrown by apt_install when the package wasn't found.