2015-01-26 11:25 GMT+00:00 Markus Koschany <a...@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.montez...@gmail.com> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
