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
On Sun, Feb 07, 2010 at 07:56:52PM +0100, Felix Schwarz wrote:
== 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.
Most likely, we would want the %postun hack to remain for the lifetime of EPEL-5 (not sure if you want to carry over into EL-6 as well). Other than that, this looks sane.
== 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'.
The tar files there are giving me permission denied but the approach sounds like it's both worth doing and that you've got a plan that works as well as anything dealing with replacing symlinks can.
-Toshio
Am 08.02.2010 18:36, schrieb Toshio Kuratomi:
The tar files there are giving me permission denied
[x] fixed
I think I forgot to mention one limitation of the upgrade hack: bacula has several database backends - however these are not pluggable (e.g. dlopen/so file). Therefore we have packages like bacula-directory-sqlite and bacula-director-mysql. Currently you can have both installed in parallel but use just one of them (that's where the alternatives come into play).
With the upgrade hack, the different db specific packages will conflict with each other. If a user has such a configuration he can not upgrade without removing one of the packages before.
fs
Am 08.02.2010 18:36, schrieb Toshio Kuratomi:
The tar files there are giving me permission denied
[x] fixed
I think I forgot to mention one limitation of the upgrade hack: bacula has several database backends - however these are not pluggable (e.g. dlopen/so file). Therefore we have packages like bacula-directory-sqlite and bacula-director-mysql. Currently you can have both installed in parallel but use just one of them (that's where the alternatives come into play).
With the upgrade hack, the different db specific packages will conflict with each other. If a user has such a configuration he can not upgrade without removing one of the packages before.
fs
On Mon, 08 Feb 2010 19:45:29 +0100 Felix Schwarz felix.schwarz@oss.schwarz.eu wrote:
Am 08.02.2010 18:36, schrieb Toshio Kuratomi:
The tar files there are giving me permission denied
[x] fixed
I think I forgot to mention one limitation of the upgrade hack: bacula has several database backends - however these are not pluggable (e.g. dlopen/so file). Therefore we have packages like bacula-directory-sqlite and bacula-director-mysql. Currently you can have both installed in parallel but use just one of them (that's where the alternatives come into play).
With the upgrade hack, the different db specific packages will conflict with each other. If a user has such a configuration he can not upgrade without removing one of the packages before.
That sounds like something to note to epel-announce when the package is pushed out to stable. (ie, why it's happening and what to do to get it working again).
The hack seems fine to me... but I also think it should just stay around in EPEL5 after it lands. You can get rid of it for RHEL6.
kevin
Hi,
yesterday I built bacula 2.4.4 in EPEL5 to fix the current upgrade problems as described previously here (2010-02-07). I just pushed the update to testing: https://admin.fedoraproject.org/updates/bacula-2.4.4-2.el5
I updated a couple of internal systems of mine without any problems. However I would like to see more testing if possible.
IMHO the update should stay in testing for 2 months. Who should I ping so that the package is not pushed automatically? Is it enough if I just don't push it to stable?
Kevin Fenzi also mentioned that this update should be mentioned on the announcement list when it hits stable. What's the process of writing an email to that list?
fs
On Sun, 14 Mar 2010 16:22:44 +0100 Felix Schwarz felix.schwarz@oss.schwarz.eu wrote:
Hi,
yesterday I built bacula 2.4.4 in EPEL5 to fix the current upgrade problems as described previously here (2010-02-07). I just pushed the update to testing: https://admin.fedoraproject.org/updates/bacula-2.4.4-2.el5
I updated a couple of internal systems of mine without any problems. However I would like to see more testing if possible.
An excellent idea. ;)
IMHO the update should stay in testing for 2 months. Who should I ping so that the package is not pushed automatically? Is it enough if I just don't push it to stable?
Make sure the web interface shows that you have unset "Enable karma automatism" so a +3 karma won't automatically push it to stable.
Kevin Fenzi also mentioned that this update should be mentioned on the announcement list when it hits stable. What's the process of writing an email to that list?
It's a moderated list: https://admin.fedoraproject.org/mailman/listinfo/epel-announce
Just explain what was changed, whats in the update, what to expect and how to provide feedback.
kevin
epel-devel@lists.fedoraproject.org