>>>>> "MAFM" == Manuel A Fernandez Montecelo <manuel.montez...@gmail.com> >>>>> writes:
MAFM> The idea is that you install libgdal1i from testing first MAFM> (1.11.2+dfsg-3), then install qgis also from testing (with all of the MAFM> versions of the dependency chain from testing). Which maybe you do, MAFM> but not shown in the actions above. Oops you are right, I never imagined you meant that I needed to adjust my sources.lists, so still haven't tried that method in fact. (And don't want to.) MAFM> In any case, gdal is in a middle of a transition [1]. In unstable, MAFM> qgis depends on libgdal.so.1-1.11.2, provided by MAFM> libgdal1i=1.11.2+dfsg-3, and qgis also depends on python-qgis, which MAFM> in turn depends on python-qgis-common, which in turn depends on MAFM> python-gdal, which depends on libgdal.so.1-1.11.3 provided by MAFM> libgdal1i=1.11.3+dfsg-2, which of course cannot stay in the system as MAFM> the same time as libgdal1i=1.11.2+dfsg-3. MAFM> So the packages will not be able to be installed/upgraded until all of MAFM> the chain of dependencies decide move on to depend on MAFM> libgdal.so.1-1.11.3 (provided by libgdal1i=1.11.3+dfsg-2), or in other MAFM> words, until the transition is over. MAFM> [1] https://release.debian.org/transitions/html/gdal-1.11.3.html So apt-get and aptitude are right, and indeed the package is uninstallable (unless one adjusts their sources.lists perhaps.) So therefore this bug should be transferred back to the offending package in the first place (please do), with the final court verdict that indeed it is doing something wrong, no?