Second Kinetic Kudu test rebuild

Christian Ehrhardt christian.ehrhardt at canonical.com
Wed Sep 21 08:08:04 UTC 2022


On Tue, Sep 20, 2022 at 9:39 PM Steve Langasek
<steve.langasek at ubuntu.com> 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/
> slangasek at ubuntu.com                                     vorlon at debian.org



-- 
Christian Ehrhardt
Senior Staff Engineer, Ubuntu Server
Canonical Ltd



More information about the ubuntu-server mailing list