On 12/20/2009 06:52 PM, Schlomo Schapiro wrote:
Hi,
did you talk to Kern about modifying Bacula so that it builds these libraries into different names and dynamically loads the correct one? This would allow the user to actually have the DB backend as a configuration option.
This could be as primitive as putting the various libraries into different subdirs of _libdir/bacula and adding the correct dir to LD_LIBRARY_PATH of the start script.
IMHO any solution you make here should go upstream...
An alternative is the use of update-alternatives as mentioned already in this thread.
Any "hacking solution" as part of the RPMs or SPEC files is likely to produce much more management overhead for you as the maintainer. You could for example build different subpackages that exclude each other. But then the user would be confronted at installation time to choose the correct database, not so intuitive to the average user as a configuration option.
Bottom line is, either Bacula solves this problem or you will have a lot of pain maintaining the RPMs. BTW, are you the author of the RPMs on http://www.bacula.org/en/?page=downloads? If not, maybe you look at the src.rpm that can be found there and how it builds the different DB backend RPMs... And of course you might merge your work back into the "official" Bacula SPEC file...
Regards, Schlomo
I based my original build on the spec file from upstream's source rpm and then adapted it for opensuse because their %post scripts don't work for suse and don't pass build service rpmlint test. I have a mysql package in Contrib but it seems there is a demand for postgresql and when I closed the bug for no x86_64 rpms for bacula, sqlite was also requested. You speak with great wisdom, if it's easy for upstream to combine the database support it will make life a lot easier for me in the long run. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org