As suggested in bug 829219; another option could be to explicitly
check the state of the user's preferences, e.g.:
if readlink /etc/alternatives/libbaccats.so | grep --silent mysql; then
# set up for mysql backend
elif readlink /etc/alternatives/libbaccats.so | grep --silent sqlite; then
# set up for sqlite backend
else
# default to postgresql backend
fi
That approach would default to postgresql backend but would retain
previously-set preferences even on version updates.
Regards,
--Simone
On 6 June 2012 19:58, Simone Caronni <negativo17(a)gmail.com> wrote:
Hello,
I need an advice on how to push an update without impacting users too much.
There's a problem in the current shipped Bacula in Fedora 17 related to shared
libraries.
This is related to the fact that upstream changed things so many times to remove the
multiple builds in the past 6 months.
I'll try to make the story as short as possible:
Starting from 5.0.3, there were multiple binaries built from the same source inside the
package, lots of symlinks in the alternatives system and lot of patches to support the
various database backends.
Starting from 5.2.x, upstream developers moved all the common code into libraries and
made the selection of the database through a single symlink on a versioned library.
At the beginning this was done with multiple versioned libraries offering a single shared
object name and tricks like that. This made packaging almost impossible (packages
requiring libraries contained in themselves, yum going crazy) and ended up with the
developers changing everything a couple of times (and the spec file followed, with %ghost,
etc.).
In the latest incarnation of the package that was released with Fedora 17 (5.2.6-2.fc17 -
unchaged for a long time), the backend was chosen with an alternative (+ a slave):
# alternatives --config libbaccats.so
There are 3 programs which provide 'libbaccats.so'.
Selection Command
-----------------------------------------------
1 /usr/lib64/libbaccats-mysql-5.2.6.so
+ 2 /usr/lib64/libbaccats-sqlite3-5.2.6.so
* 3 /usr/lib64/libbaccats-postgresql-5.2.6.so
Enter to keep the current selection[+], or type selection number:
The problem is that when I tried to install 5.2.7-2.fc17 from a freshly built package I
ended up in this situation:
# alternatives --config libbaccats.so
There are 6 programs which provide 'libbaccats.so'.
Selection Command
-----------------------------------------------
1 /usr/lib64/libbaccats-mysql-5.2.6.so
+ 2 /usr/lib64/libbaccats-sqlite3-5.2.6.so
* 3 /usr/lib64/libbaccats-postgresql-5.2.6.so
4 /usr/lib64/libbaccats-mysql-5.2.7.so
5 /usr/lib64/libbaccats-sqlite3-5.2.7.so
6 /usr/lib64/libbaccats-postgresql-5.2.7.so
I fixed the thing in 5.2.7-3.fc17 (in koji), simply linking the unversioned shared object
to the alternatives file and removing the slave.
# alternatives --config libbaccats.so
There are 3 programs which provide 'libbaccats.so'.
Selection Command
-----------------------------------------------
1 /usr/lib64/libbaccats-mysql.so
2 /usr/lib64/libbaccats-sqlite3.so
*+ 3 /usr/lib64/libbaccats-postgresql.so
What's the procedure to push this update into updates-testing (and updates)?
There's some cleanup of alternatives involved.
Thanks,
--Simone
--
You cannot discover new oceans unless you have the courage to lose sight of the shore (R.
W. Emerson).
--
You cannot discover new oceans unless you have the courage to lose
sight of the shore (R. W. Emerson).