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 <wande...@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. : )
