Your message dated Thu, 30 Apr 2020 13:05:11 +0200 with message-id <[email protected]> and subject line Re: Bug#946285: libgcc-s1: probably needs Breaks: libgcc1 (<< 1:10) has caused the Debian Bug report #946285, regarding libgcc-s1: probably needs Breaks: libgcc1 (<< 1:10) to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 946285: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946285 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---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
--- End Message ---
--- Begin Message ---On 12/17/19 12:48 PM, Matthias Klose wrote: > On 06.12.19 20:32, Simon McVittie wrote: >> On Fri, 06 Dec 2019 at 17:49:09 +0100, Matthias Klose wrote: >>> On 06.12.19 17:36, Simon McVittie wrote: >>>> I notice gcc-10 has switched from packaging libgcc_s.so.1 as >>>> "libgcc1" to the Policy-recommended name libgcc-s1. >>> >>> it's not an old version, it's the same version. Is this still an issue? >> >> Oh! I hadn't realised libgcc1 (>= 1:10) still had content - I assumed it >> had become an empty dependency package. >> >> In that case, it looks as though libgcc1 (>= 1:10) and libgcc-s1 >> (>= 1:10) are not going to be co-installable on systems with merged /usr >> (such as default buster installations), because they contain a path that >> differs only in whether it starts with /lib or /usr/lib. >> >> libgcc1 (<< 1:10) and libgcc-s1 (>= 1:10) would have the same problem, >> in fact, so I should have suggested Breaks/Replaces. > > 10-20191209 now has the libgcc1 package as a non-multiarch package, and > shipping > the library in /lib to avoid the conflict. libgcc-s1 is M-A: same, providing > the > libgcc1 package. > >>> well, currently the very same library is shipped, so I don't see what could >>> break. The current packaging doesn't need any breaks. >> >> It won't break *full* upgrades on non-merged-/usr systems right now, >> but it could break partial upgrades where you have for example >> >> libgcc1 (= 1:9.2.1-21) from gcc-9 >> libgcc-s1 (= 10-20191205-1) from gcc-10 >> >> if there is no dependency relationship that forces that situation not >> to happen. >> >> Is there a reason why this rename and file move particularly needs to >> happen, or is it just for neatness? The changelog doesn't mention it, >> but I can see that it might have implications for the interaction with >> ${multiarch:breaks}. >> >> If it's just for neatness, to be honest I'd be inclined to leave it >> as-is and consider it to be a historical accident, the same as the way >> libglib2.0-0 isn't called libglib-2.0-0 as it should be. > > The libgcc1 binary has a different version number than any other binary built > from gcc-10. Dropping that allows some simplification in the packaging. Yes, > you > could argue that an epoch bump would work as well, but I'd like to avoid that. > closing now, the upgrades went fine, afaics.
--- End Message ---
