On 06.12.19 17:36, Simon McVittie wrote: > 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.
it's not an old version, it's the same version. Is this still an issue? > 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? I tried that, but then apt wants to remove an essential package, and asks the interactive question. And still the Pre-Depends will leave a small window without the library being installed. > 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. well, currently the very same library is shipped, so I don't see what could break. The current packaging doesn't need any breaks. > 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. Sure, the package will be in experimental for a few more months. Matthias
