--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: libgcc-s1: probably needs Breaks: libgcc1 (<< 1:10)
- From: Simon McVittie <smcv@collabora.com>
- Date: Fri, 6 Dec 2019 16:36:07 +0000
- Message-id: <20191206163607.GA900699@horizon>
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 ---