Upgrade hack for bacula in EPEL5
Hi,
== summary ==
The current bacula package in EPEL is faulty. I built an upgrade hack so that
we don't require manual intervention by sysadmins. In order to get it right
this time, an rigorous review is desirable.
== background ==
The bacula package (storage+director) in EPEL5 which is shipped since
September 2007 contains a nasty bug in the %post/%postun scriptlets. If the
package is ever updated, a symlink will be missing and bacula will not start
anymore. This can be fixed e.g. by a manual install/uninstall of the bacula
package.
This error was present in Fedora but was fixed there a long time ago.
== current situation ==
We can not update the bacula package (e.g. for security reasons) without
breaking a lot of installs.
== plan for attack ==
The old package will remove the symlink generated by alternatives during
%postun unconditionally (also during upgrade). Therefore we replace the
symlink in the new package with a copy of the real file, alternatives won't
touch it and the user is happy.
After some time when everyone ("almost everyone") upgraded, we ship another
update which reverts this ugly hack.
== current implementation ==
I have a series of spec file patches which implement the fix:
http://www.felix-schwarz.name/files/misc/2010/bacula_upgrade_hack/
Also I built some test scripts which check some install/uninstall/upgrade
procedures. I wrote at least some lines how to use them in 'how_to_test.txt'.
Scratch builds:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1964332
http://koji.fedoraproject.org/koji/taskinfo?taskID=1964343
http://koji.fedoraproject.org/koji/taskinfo?taskID=1964372
== roadmap ==
I would like to gather as many reviews as possible on that issue:
- Is this issue worth tackling?
- Is my plan of action sane?
- Any other issues?
1) Wait for reviews+suggestions (1-2 weeks)
2) Commit/build (assuming that the plan is approved)
3) Push a new bacula to testing (2 months)
4) Push bacula to stable
5) Revert upgrade hack
[ ] done
fs