Hi, On 25-03-2022 22:36, Sylvestre Ledru wrote:
I think you under estimate the complexity of the problem.
That may very well be. In that case it's even more important we have this discussion, because I believe it's important that the Release Team understands.
llvm defaults is probably going to be 14 for bookworm.
Ack.
We will probably have 13, 14 and 15. I hope that packages like ghc will be able to use one of this version (this is usually the blocker).
I understand that 12 can probably be removed soon. Do you have any expectation when 11 can be removed?
1) At all times, no more than three versions of llvm in unstable and testing. You can upload and prepare in experimental, but uploads to unstable tend to raise expectations of people that they can use it. 2) Which means, that before a new version can be introduced, we have to get rid of one of old ones. If we're better at communicating the plan, we can be more aggressive in removing packages that don't migrate to one of the supported versions.I wish it was that easy. It isn't about llvm itself but the packages using it (or clang & co).
I wonder if you misunderstood me. I *think* that you refer here to my last point and I *suspect* you believe that I meant removal of old llvm version. That as least was not what I meant. I meant reverse dependencies. I hope that makes more sense. If not and it is how you understood me, that I wonder why you believe removing reverse dependencies isn't that easy. That would only makes sense to me if key packages would most of the time be targeting different versions of llvm and it would be hard to settle on a common baseline. But maybe you had something else in mind. Please elaborate then.
Paul
OpenPGP_signature
Description: OpenPGP digital signature
