On 02/09/15 14:23, Steve M. Robbins wrote:
> Well, insighttoolkit (v3) is also marked for autoremoval next week, so my
> plan
> is to let that happen -- and I presume the depending packages will also be
> removed at that time.
Autoremoval only removes packages from testing, and ftp-master removals
from unstable (unlike autoremovals from testing) are not normally
recursive. If you want the ftp-masters to remove reverse-dependencies
from unstable, someone needs to say so. For example, ogre-1.8 is another
C++ package in the same situation as insighttoolkit 3 ("this is obsolete
and the maintainer will not transition it, but things still depend on
it"). Neil Williams recently resolved that by asking the ftp-masters to
remove the remaining reverse-dependencies of ogre-1.8 from unstable.
Any C++ library in unstable that uses one of the affected features
(std::string, std::list, possibly std::function) will break its ABI when
rebuilt with g++-5, and all packages depending on affected libraries
need rebuilding; so all such libraries are part of the wider libstdc++
transition, even if they are RC-buggy or not present in testing. I think
non-rebuilt libraries might also prevent the old binary packages on
which they depend from being "decrufted" without manual intervention,
although I could be wrong.
How long ago were maintainers of packages depending on insighttoolkit 3
told that it was obsolete and going to be removed?
> I haven't checked, but I will be conservative and assume it needs transition.
>
> I have already staged v4.8 in experimental for that purpose; see also #793250
> and #796561.
Thanks, I've noted those on the Titanpad. I will not open a separate bug
here, since #796561 can act as the tracking bug.
S
