Bug#946285: libgcc-s1: probably needs Breaks: libgcc1 (<< 1:10)

[Simon McVittie <smcv@collabora.com>]

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.

> 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.

> > 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.
> 
> Sure, the package will be in experimental for a few more months.

The weirdness we had with GLib involved a version from jessie causing
trouble for people upgrading buster-as-testing systems 3-4 years later,
and experimental has few users; so if you get similar upgrade issues,
I suspect you won't see them until it's already too late.

You might avoid this for libgcc, because GLib has the usual
Autotools-style layout of most shared libraries:

    regular file libglib-2.0.so.0.1234.56
    link         libglib-2.0.so.0 -> libglib-2.0.so.0.1234.56
    SONAME       libglib-2.0.so.0

whereas libgcc1, unusually, only has:

    regular file libgcc_s.so.1
    SONAME       libgcc_s.so.1

so maybe the failure mode from GLib can't occur here? We still don't
know the root cause of the failure mode from GLib, though, so perhaps
that difference doesn't help you.

    smcv