On 2024-03-06 12:53:02 -0800, Steve Langasek wrote: > On Thu, Mar 07, 2024 at 01:43:11AM +0500, Andrey Rahmatullin wrote: > > On Wed, Mar 06, 2024 at 12:33:08PM -0800, Steve Langasek wrote: > > > > > Are there instructions on how to progress an unstable system through > > > > > this, or is the repo currently in a known inconsistent state? I have > > > > > tried upgrading various packages to work through deps but I am unable > > > > > to do a dist-upgrade for a while. > > > > Being unable to do a dist-upgrade is expected and some packages can't be > > > > installed or can't be upgraded, but in general on amd64 you should be > > > > able > > > > to upgrade a majority of them with `apt upgrade` and then manual > > > > installing/upgrading, if you wish so (as in theory most libfoo0t64 are > > > > drop-in replacements for libfoo0, but in practice some packages have > > > > additional abi deps for their plugins etc., plus the usual amd64-i386 > > > > skews, plus some unique problems in some packages). > > > > Also debootstrapping sid is broken, or may be broken from time to time. > > > > Install testing instead if that's good enough. > > > > Aside from the libuuid1t64 revert, for which binNMUs have been scheduled, > > > I > > > actually would expect unstable to be dist-upgradeable on non-32-bit archs: > > > either the existing non-t64 library will be kept installed because nothing > > > yet needs the t64 version, or something does want the t64 version and apt > > > will accept it as a replacement for the non-t64 version because it > > > Provides: > > > the non-t64 name. > > > > So once the libuuidt64 revert is done (later today?), if apt dist-upgrade > > > is > > > NOT working, I think we should want to see some apt output showing what's > > > not working. > > On my system there is currently only one problem not related to libuuid: > > vlc-plugin-pipewire is not rebuilt for vlc-plugin-abi-3-0-0ft64. As for > > uuid, I have several i386 libraries installed that depend on it. > > That seems like a case where the maintainer (cc:ed) could add the > vlc-plugin-abi-3-0-0f Provides: on 64-bit archs for backwards-compatibility > to unblock. Or someone can just request binNMUs for this package sooner > rather than later. (It's premature to request mass binNMUs yet while arm* > are still being re-bootstrapped.)
The Provides in this case would not be enough as it directly maps to the symbol postfix used by the plugin loader. I'd also need the corresponding #ifdef to only switch the symbol postfix on the affected architectures. Cheers -- Sebastian Ramacher
