Bug#776260: tecnoballz: Version dependancy to libsdl-mixer1.2

[Manuel A. Fernandez Montecelo]

2015-01-26 11:25 GMT+00:00 Markus Koschany <apo at gambaru.de>:
> On 26.01.2015 02:44, Celelibi wrote:
>> Package: tecnoballz
>> Version: 0.93.1-2
>> Severity: normal
>>
>> Hello,
>>
>> The sound of tecnoballz version 0.93.1-2 wasn't working with libsdl-mixer1.2:i386
>> version 1.2.12-5.
>> The error message was:
>> handler_audio::play_music() Mix_LoadMUS return Failure loading module header
>>
>> But it did work after upgrading to 1.2.12-11+b1. Maybe the dependancies
>> should be updated.
>>
>> Regards,
>> Celelibi
>
> Hello,
>
> CCing Manuel the maintainer / uploader of sdl-mixer1.2 for feedback.
>
> This is somewhat strange because there is no version 1.2.12-5 in the
> official archive anymore. Stable has 1.2.12-3 and testing/unstable
> 1.2.12-11+b1. Did you put libsdl-mixer1.2 on hold? However I believe I
> understand the problem and you are right, there should be a versioned
> dependency on libsdl-mixer1.2 (>= 1.2.12-11+b1). I'm not sure whether
> this is a bug in tecnoballz or libsdl-mixer1.2.

Indeed, sdl-mixer1.2 -11+b1 was just a scheduled "binary NMU" version
to build against the newer libmikmod3 (library transition):

BinNMU changelog for sdl-mixer1.2 on amd64, armel, armhf, hurd-i386,
i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x and
sparc:
Rebuild against libmikmod3


> In wheezy libsdl-mixer1.2 depends on and links against libmikmod2.
> However the latest version of libsdl-mixer1.2 in testing links against
> libmikmod3. Since the dependency on libsdl-mixer1.2 is satisfied, this
> package won't be upgraded if you mix different Debian distributions.
>
> In the meantime tecnoballz links against libmikmod3 while you are still
> using the old libsdl-mixer1.2 that links against libmikmod2. So there is
> a version mismatch here.
>
> The dependency on libsdl-mixer1.2 is unversioned because this package
> does neither provide a .symbols file like for instance libsdl-image1.2
> nor does it provide a shlibs file for inserting a versioned dependency.
>
> I can solve this problem in tecnoballz but I wonder if libsdl-mixer1.2
> should rather use a symbols file or the dpkg-shlibdeps mechanism to fix
> this for all packages depending on libsdl-mixer1.2 and libmikmod3.
>
> Manuel, what do you think about it?

I am not sure if there's a clear way to solve this problem.

In principle, neither tecnoballz nor sdl-mixer1.2 are doing anything
wrong, and they could not have been set-up differently at the time of
uploading them to the archive other than depending on an exact version
of mikmod, and this would be very problematic for transitions (they
would make very complicate to migrate from the version of mikmod
providing libmikmod2 to the version providing libmikmod3; and of
course this possible solution would have to be done for every other
library that sdl-mixer1.2/tecnoballz/etc depends on).

After knowing this problem, we could upload a new package revision of
sdl-mixer1.2 requiring the most recent version of mikmod (or
tecnoballz depending on versions of sdl-mixer1.2 compiled against
libmikmod3), but in that case the issue is not scalable because it
would have to be done potentially for every library that a package
depends on.  I don't think that Release Managers will accept this
change for the next stable Jessie at this point.

It seems to me that the fundamental problem is that several versions
of mikmod cannot work or be loaded in memory at the same time, which
could maybe be solved by symbol versioning in the shared library, or
otherwise via a conflict of the binary package libmikmod3 with the
previous version of libmikmod2 (so the package managers like apt would
either prevent to install tecnoballz, or to force to upgrade to a
recent version of sdl-mixer1.2 compiled against libmikmod3; in this
particular case).

I also think that using a mix of versions like sdl-mixer1.2_...-5,
which was only present in unstable for a brief period of time (~5
weeks) 1.5 years ago while using recent versions of packages like
tecnoballz and mikmod is not very well supported in Debian because of
reasons like this one, of incompatible versions of interdependent
libraries.

So in short, I am not sure about what to do in this case, specially for Jessie.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>