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