| From: | Christoph Berg <myon(at)debian(dot)org> |
|---|---|
| To: | Bradford Boyle <bradford(dot)d(dot)boyle(at)gmail(dot)com> |
| Cc: | pgsql-pkg-debian(at)postgresql(dot)org |
| Subject: | Re: vip-manager and vip-manager2 FTBFS |
| Date: | 2024-08-16 09:53:52 |
| Message-ID: | Zr8hsBoEnKLPlGSN@msg.df7cb.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-pkg-debian |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christoph Berg | 2024-08-16 10:30:14 | Re: Systemd may start PostgreSQL cluster before time is properly setup on the host machine |
| Previous Message | Christoph Berg | 2024-08-15 13:16:37 | The end of 32-bit PostgreSQL support in Debian |