Bug#946285: libgcc-s1: probably needs Breaks: libgcc1 (<< 1:10)
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.
Reply to: