On Tue, Sep 20, 2022 at 9:39 PM Steve Langasek <[email protected]> wrote: > > On Tue, Sep 20, 2022 at 12:16:37PM +0200, Christian Ehrhardt wrote: > > > But by the related discussions it seems pgsql isn't ready for llvm-15 yet > > and changing the symbol to overcome the build error might lead to more > > subtle and sinister issues later on. > > I guess to avoid unknown further fallout in Kinetic, instead of trying > > to fix the bug in pgsql partially to fail later it is better - for now - to > > change the pgsql build dependency to llvm-14-dev. > > AFAICS libllvm14 + libllvm15 are in main in Kinetic still and postgres as > > well as maybe others will need to stick with the safer one for now. > > > For a minimal rant, postgresql just moved to llvm 14, also in Debian llvm-15 > > is only in experimental. Who knows how many more subtle changes there are > > breaking things (also in other packages). It might have been a bit too > > aggressive to move that into kinetic-release so much after feature > > freeze ([5] shows 14th Sept). It seems to be the same core-lib/toolchain > > discussion we have too often. > > The rationale for allowing late landing of llvm-defaults to date has been > that almost no packages in the archive build-depend on the unversioned > -defaults packages *because* the behavior changes frequently in incompatible > ways. It is thus not realistic that we ship only one version of > llvm-toolchain in a release (despite the small number of > reverse-build-dependencies vs gcc), and the target of -defaults matters much > less.
Thanks for the explanation, it always helps to follow the thoughts behind why things happened. > We should make it a condition of this late landing that > reverse-build-dependencies of llvm-defaults get build-tested after the > update, and any that prove incompatible move to a versioned build-dep. Great idea, that (switch to versioned dep) is exactly what I did to resolve our case. And I believe it would indeed help if those builds could be checked as part of landing of the new version. > As far as this being experimental-only, there are lots of reasons why a > package might be in experimental that may or may not be relevant to Ubuntu. > It is not experimental upstream but has had its GA release, and that's the > version that we have in kinetic. > > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > Ubuntu Developer https://www.debian.org/ > [email protected] [email protected] -- Christian Ehrhardt Senior Staff Engineer, Ubuntu Server Canonical Ltd -- ubuntu-server mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
