Re: Bug #961990
On 2020-07-19 at 16:27, Stefan Monnier wrote:
>> This has been going on since the beginning of June, 2020, with no end in sight.
>> Bug #961990 - IIUC, no activity since 2020-06-02.
>>
> You show a session where you reject all the proposed solutions, but
> I don't see any justification why you reject those choices, so I don't
> know what you consider to be a bug.
>
>> Remove the following packages:
>> 1) libgcc1 [1:10.1.0-1 (now, unstable)]
>> Accept this solution? [Y/n/q/?] n
>>
> I said `y` here and lived happily ever after.
Yes. Each time (many times, since the beginning of June) I went
through the solutions offered, each worse than the last. I consider
Bug #961990 to be just that - a bug. I do wish that if this bug is
not going to be fixed, that the maintainers would say so.
The least "damaging" solution offered seemed to be, as you noted, to
remove libgcc1. I have often been tempted to do that, just to not
have 12 stale packages hanging around each time I update. I may end up
removing libgcc1, since I do not currently do any C programming, but I
hope that would not "come back to bite me".
On Sun, Jul 19, 2020 at 4:42 PM The Wanderer <wanderer@fastmail.fm> wrote:
> As he made clear later on, he rejected this because he has (or wants to
> have) packages from external repositories which depend on libgcc1 by
> that name and which he isn't willing to give up.
>
> IOW, not only is he running sid (unofficial motto: "whenever it breaks,
> you get to keep all the pieces"), he's also running a partial
> FrankenDebian (those external repositories' URLs indicate that they
> correspond to buster, not to sid), and is complaining that an apparently
> internally consistent state of packages in sid isn't consistent with the
> state of packages in those external repositories.
>
> The only solution here I can think of offhand would be to rebuild the
> packages from those external repositories to reflect the new package
> names that exist in sid. As it happens, libgcc-s1 is also the package in
> testing at the moment (albeit at an earlier version), so there's more of
> a case for convincing the upstreams of those repositories to do that
> rebuild now rather than later - but it's probably theoretically possible
> to do it locally, too.
>
> (Well, switching to track a newer-than-buster version of those external
> repositories, or to track buster itself instead of sid for the internal
> repositories, would also resolve the conflict. But the former may not
> exist, and the latter would involve significant downgrades from what
> he's probably already installed, so neiterh is likely to be considered a
> real solution.)
>
> --
> The Wanderer
>
> The reasonable man adapts himself to the world; the unreasonable one
> persists in trying to adapt the world to himself. Therefore all
> progress depends on the unreasonable man. -- George Bernard Shaw
>
I am puzzled that you refer to a FrankenDebian, using external repositories.
The original installation was made 2018-08-10, just before the switch
from Stretch to Buster. I IMMEDIATELY upgraded to Unstable, with this
/etc/apt/sources.list:
--------------------
# deb cdrom:[Debian GNU/Linux 9.4.0 _Stretch_ - Official amd64 NETINST
20180310-11:21]/ buster contrib main non-free
deb http://ftp.us.debian.org/debian/ unstable
main non-free contrib
deb-src http://ftp.us.debian.org/debian/ unstable
main non-free contrib
# deb http://security.debian.org/debian-security buster/updates
main non-free contrib
# deb-src http://security.debian.org/debian-security buster/updates
main non-free contrib
# buster-updates, previously known as 'volatile'
# deb http://ftp.us.debian.org/debian/ buster-updates
main non-free contrib
# deb-src http://ftp.us.debian.org/debian/ buster-updates
main non-free contrib
--------------------
Here is my current /etc/apt/sources.list:
--------------------
# deb cdrom:[Debian GNU/Linux 9.4.0 _Stretch_ - Official amd64 NETINST
20180310-11:21]/ buster contrib>
deb http://ftp.us.debian.org/debian/ unstable
main contrib non-free
# deb-src http://ftp.us.debian.org/debian/ unstable
main contrib non-free
# deb http://security.debian.org/debian-security buster/updates
main contrib non-free
# deb-src http://security.debian.org/debian-security buster/updates
main contrib non-free
# buster-updates, previously known as 'volatile'
# deb http://ftp.us.debian.org/debian/ buster-updates
main contrib non-free
# deb-src http://ftp.us.debian.org/debian/ buster-updates
main contrib non-free
--------------------
The only uncommented line seems to be:
deb http://ftp.us.debian.org/debian/ unstable
main contrib non-free
I did not use Testing on the way to Unstable, and have always
scrupulously avoided third party repositories of any kind. And I have
no intention of trying to downgrade to Buster, or even Testing. I do
not mix repositories between Stable, Testing and Unstable. I really
do know better than that.
--------------------
Am I missing something?
BTW, I love the classic quote from George Bernard Shaw.
: )
Reply to: