Package: libgcc-s1 Version: 10-20191205-1 Severity: important I notice gcc-10 has switched from packaging libgcc_s.so.1 as "libgcc1" to the Policy-recommended name libgcc-s1. Because libgcc-s1 contains /usr/lib/MULTIARCH/libgcc_s.so.1 and libgcc1 contains /lib/MULTIARCH/libgcc_s.so.1, the new libgcc-s1 and the old libgcc1 do appear to be co-installable. However, if both are installed, programs that were compiled against the newer version will load the older version (because /lib/MULTIARCH is more preferred by the dynamic linker than /usr/lib/MULTIARCH), and that isn't necessarily going to work. I would recommend adding a versioned Breaks to force libgcc1 to be upgraded to the empty transitional version from gcc-10, unless there is some reason I'm not seeing right now that makes this unnecessary.
Because libgcc is so important, you might want to give the transitional libgcc1 a Pre-Depends on libgcc-s1 instead of its current Depends? Otherwise, I think there can be a time during installation in which the old libgcc has been deleted by installing and the new one has not yet been unpacked. Like all Pre-Depends, this should be discussed on -devel first. I should also warn you that even after adding the necessary Breaks, you might also encounter bugs similar to https://bugs.debian.org/894763 and https://bugs.debian.org/896019, which appeared when GLib moved from /lib/MULTIARCH to /usr/lib/MULTIARCH - somehow an obsolete copy of GLib continued to exist in /lib/MULTIARCH, breaking programs. We still don't understand how or why that happened. I asked the technical committee for advice in https://bugs.debian.org/911225 and they suggested adding diagnostic/cleanup code to GLib's maintainer scripts, but I haven't been able to implement that yet. If similar bugs happen with libgcc, they would be more serious than they are for GLib, since some of the programs and libraries that you'd want to use to recover from that situation, notably apt, depend on libgcc. Thanks, smcv
