2015-01-27 10:47 GMT+00:00 Markus Koschany <a...@gambaru.de>: > 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".
Well, if the hypothesis that v2 and v3 cannot be loaded in memory at the same time is correct, I think that the Conflicts is the most (or only) correct one, since this will not only happen with tecnoballz -- it can potentially happen with any other packages in people's systems, if the applications were compiled at different points in time (not only in Debian but derivatives, private repos, Steam stuff, etc). I understand that this can be more difficult/cumbersome to get implemented than a simple change in tecnoballz to solve the problem, for example, so I understand if you want to do this. I don't think that forcing rev-deps to add a more strict dependency on libsdl-mixer1.2 when they actually don't have any problems is a very good solution (althought that it does not matter very much, since I expect that most people will upgrade anyway). >> 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 am not 100% sure, but don't think that partial upgrades are supported, or problems derived from that considered release-critical. > I'm fine with either one of the solutions above and I would file an > unblock request. What do you prefer? As I said above, I am not very convinced that either this solution or the one involving changes to sdl-mixer1.2 is correct and solves all problems potentially created in this case (maybe no solution is 100% satisfactory for all cases if the library is not backwards compatible). So I would prefer not to do it for sdl-mixer. Modifying tecnoballz is probably the easiest/quickest, and it is probably going to get approved without much hassle from release managers. 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
