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 <negativ...@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).
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
