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.