On 26.01.2015 20:25, Manuel A. Fernandez Montecelo wrote: [...] > 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.
Thanks for your detailed reply. I guess it is much simpler. I was
thinking about two possible solutions because I believe there simply
should be a tighter dependency on libsdl-mixer1.2.
* You could add an override for dh_makeshlibs to libsdl-mixer1.2
dh_makeshlibs -V 'libsdl-mixer1.2 (>= 1.2.12-11+b1)'
After that we would just need to request a binNMU for tecnoballz.
* I could depend on libsdl-mixer1.2 (>= 1.2.12-11+b1), overriding the
values of the shlibs:Depends substvar.
It seems tecnoballz is the only reverse-dependency of libsdl-mixer1.2
that directly depends on libmikmod3 at the same time. So we should be
fine with either way.
> 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).
That explanation makes sense. A Conflicts: libmikmod2 would also be a
solution, although I think the ones I mentioned above are more "correct".
> 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.
The problem still exists, otherwise I wouldn't bother. It is easily
reproducible if you upgrade from wheezy to jessie. This is only a
problem if you mix different distributions instead of doing a
full-upgrade from wheezy to jessie. Nevertheless it is a bug, the
question is, is it release-critical?
I'm fine with either one of the solutions above and I would file an
unblock request. What do you prefer?
Regards,
Markus
signature.asc
Description: OpenPGP digital signature
