Update impacting users (not so many I hope)

[Simone Caronni]

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 at 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).