Bug#1121561: libc++-19-dev: breaks libc++1-19, not just libc++1

[Matthias Klose]

On 11/29/25 06:09, Andres Salomon wrote:
> Control: found -1 1:19.1.7-18
> Control: notfound -1 1:19.1.7-10.1
> 
> 
> On Fri, 28 Nov 2025 23:49:35 -0500 Andres Salomon <dilinger at queued.net> 
> wrote:
>> Control: severity -1 serious
>>
>> FYI, this bug should be higher priority. I hit it as well.
>>
> 
> 
> Also, fwiw, I don't think llvm-toolchain-19 should've changed the libc+ 
> +*/libunwind/libgom package names. I consider 19 old at this point; it 
> was released with trixie, I expect (and hope) it will be removed before 
> forky. Just doing the library renames in llvm-toolchain-21 and later 
> means later on you mainly need to deal with apt upgrades from major- 
> versioned-libs 19 to non-major-versioned-libs 21/22+, rather than a mix 
> of major-versioned and non-major-versioned lib 19 packages. That's my 
> opinion, at least.

Doing them in 21 doesn't help with testing these.  It is very unlikely 
to ship just one LLVM version in a release, so you have to be prepared 
for a transition.  Your merged patch unfortunately was very incomplete, 
without handling upgrades from experimental, without having these libs 
as M-A: same and without building older LLVM versions without these 
libraries, so that packages still can be uploaded to the archive. So do 
this upgrade testing early in the release cycle, and be confident that 
it then works later.

Adoption of new LLVM version should be supported, and not delayed, like 
in the last release cycle (by the release team blocking migration of 17 
and 18), or now by not introducing 20.  Just choosing some version, and 
hoping that every third party package will adopt to it is mostly wishful 
thinking. I don't think that having a version more or less is that 
important.

Anyway, fixing the upgrade issues over the weekend.