Thread: vip-manager and vip-manager2 FTBFS

Hi All,

The package golang-etcd-server-dev was updated from 3.4.30 to to 3.5.15
at the end of July. This version of etcd introduced a couple of changes
to import paths that caused vip-manager and vip-manager2 to FTBFS in sid
[1, 2]. I've prepared patches for both packages to update the import
paths [3, 4]. With these patches, both packages build on sid and
autopkgtests pass.

However, bookworm has etcd 3.4.23 and noble has 3.4.30 so the patches
break the build on older distributions. I don't believe this is an issue
for vip-manager since this pakcage provides vip-manager 1.x which hasn't
had a new release since 2022. vip-manager2 has had a release as recently
as three weeks ago. If we want to build updated packages of vip-manager2
for both bookworm and trixie on pgdg, we would need to apply different
patches for etcd 3.4 and 3.5.

I suppose we could also just disable vip-manager2 for any distribution
besides sid and trixie but I don't have a sense of how popular this
package is and if that is a viable solution for this particular package.

Before updating these packages, I wanted to see if there was any input
on how to handle these packages on older distributions.

Thanks,
-- Bradford

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078322
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078323
[3]: https://salsa.debian.org/postgresql/vip-manager/-/commit/ac57eaba565013c462da95276db4824af3069beb
[4]: https://salsa.debian.org/postgresql/vip-manager2/-/commit/244ba273f40125861603403064171e2736a2978d

Re: Bradford Boyle
> I suppose we could also just disable vip-manager2 for any distribution
> besides sid and trixie but I don't have a sense of how popular this
> package is and if that is a viable solution for this particular package.
> 
> Before updating these packages, I wanted to see if there was any input
> on how to handle these packages on older distributions.

etcd is often run independently on the network, so might be a version
unrelated to the local OS. Supporting v1 and v2 APIs in parallel make
sense to some degree.

And then there's the problem of different etcd-client module versions
on top. I was talking to Pavlo about this yesterday and he suggested
"go replace":
https://thewebivore.com/using-replace-in-go-mod-to-point-to-your-local-module/
But I think this solves a different problem than we have.

The way to go is probably still patches for the respective etcd-client
versions, and enabling them in debian/patches/series from
generate-pgdg-source depending on the distribution targeted.

Or we might try "go get" on that module if a distribution other than
sid/testing is being built. (Unsure how to best hook that into the
build process, possibly via logic in debian/rules.)

Christoph

Re: Bradford Boyle
> I've pushed my changes for vip-manager and vip-manager2 packages to
> salsa and attached is patch for gnerate-pgdg-source that selectively
> enable/disable the patches depending on the distributions. I have
> manually tested the sed commands and that the resulting source package
> builds on sid and bookworm.

Thanks!

Unfortunately, Go is a mess, and there was still a build problem on
jammy where it worked before and is now broken for whatever reason:

11:52:57 src/github.com/cybertec-postgresql/vip-manager/checker/etcd_leader_checker.go:15:2: cannot find package
"go.etcd.io/etcd/client/v2"in any of:
 
11:52:57     /usr/lib/go-1.18/src/go.etcd.io/etcd/client/v2 (from $GOROOT)
11:52:57     /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/src/go.etcd.io/etcd/client/v2 (from $GOPATH)

I gave up and just copied the binaries from bullseye to jammy, which
is already done for buster and focal anyway.

Christoph