Le 25/03/2022 à 22:00, Paul Gevers a écrit : > Hi Sylvestre, > > On 18-10-2021 22:42, Sylvestre Ledru wrote: >>> So, please share your plans with us. >> My target is to have 2 versions for the next release. Realistically, >> because of all the use >> cases (ex: ghc), it is hard to have all packages focusing only one >> version of llvm. > > You recently added llvm-14, we already (still) have three versions in > testing. We're going in the wrong direction.
I think you under estimate the complexity of the problem. I am not adding more packages because it is fun but because it is required to keep adequate quality. > >> Currently, I am clearly failing at this. ;) >> LLVM upstream is going through some significant changes in term of build >> systems. I have been focusing >> on bringing 12 & 13 at this level (they both have failures currently). >> >> Once they are green, I will work on the transition to 12 or (probably?) >> 13 and the removal of the older. > > I have a proposal, let's try to control this a bit better. We have > multiple other "systems" in Debian where we handle multiple versions > (like Python, Ruby, ...), but I hear your "hard to have ..." problem. > I propose: > 0) We plan to have at most two versions of llvm in the release. Can > you make a proposal for bookworm, which versions do you plan we will > ship? Sebastinas asked me the same question a few days ago. llvm defaults is probably going to be 14 for bookworm. 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). > 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). Cheers, Sylvesre