This article is being updated. Please be aware the content herein, not limited to version numbers and slight syntax changes, may not match the output from the most recent versions of Bright. This notation will be removed when the content has been updated.
Why does it happen?
Bacula is a backup application, PBS Pro is a job scheduler. The two are quite unrelated, so why should bacula have a dependency on pbspro?
The dependency is actually due tobacula-director-postgresqlbacula-storage-postgresql
which depend on a postgres library (libpq.so.5 in Bright Cluster Manager 5.2). When resolving dependencies, yum settles on the first application it finds with that library, which is pbspro and suggests this to the administrator as a solution.
Unless actually using pbspro, an administrator would probably find this an inelegant solution.
What’s the fix?
Ideally the dependency should be fixed by defining dependencies for bacula-*-postgresql better. This is outside of Bright Computing’s control.
However two simple workarounds that the administrator can carry out are to:
- Run “yum install postgresql84-libs” before installing bacula (the exact version to install can be found with a “yum provides libpq.so.5”).
- (assuming pbspro is not to be added) Add pbspro to the exclude list line in /etc/yum.repos.d/cm.repo. The line normally has an exclude option for parted already. The modified line then becomes: exclude = parted pbspro
Another workaround (based on yum autoprov) that should prevent installing pbspro unnecessarily will be implemented in Bright 6.0+