Subject: Packages for pg_doorman

From: Smolkin Grigory <[email-masked]>
Date: Wed, 12 Mar 2025 16:10:58 +0300

Hello, PGDG Team!

We would like to introduce pg_doorman, a new open-source PostgreSQL
connection pooler available under the MIT license.
You can find the project here:
github.com/ozontech/pg_doorman

It would be nice to make pg_doorman available via the PGDG repository and
we would appreciate your guidance on how to proceed.

Key Considerations:
Debian Infrastructure: We can for sure provide the necessary "debian/"
infrastructure if requested.
Rust Dependency: pg_doorman is written in Rust and requires rustc version
1.70.0 or higher.
However, we’re unsure if this version is available in all Debian-based
distributions via their default package repositories.
Build Process:
Would it be acceptable to install the compiler from https://rustup.rs/
during package building?
Alternatively, would providing Dockerfiles for respective distributions be
a viable option?

We’re open to any suggestions and requirements you may have.
Best regards!

---

From: Christoph Berg <[email-masked]>
Date: Wed, 12 Mar 2025 14:43:17 +0100

Re: Smolkin Grigory
> github.com/ozontech/pg_doorman

Hi,

thanks for the suggestion!

> Rust Dependency: pg_doorman is written in Rust and requires rustc version

This would be the first PG-related package using rust, I would expect
a lot of rust crate packages to be still missing.

> distributions via their default package repositories.

Debian stable has 1.63, unstable has 1.85.
Ubuntu noble has 1.75.

> Alternatively, would providing Dockerfiles for respective distributions be

Everything for the build needs to come from proper .deb packages from
within the target distribution. We might consider using some backports
or relaxing the rules a bit for the older distributions, but we really
like to have packages built properly for Debian main.

> We’re open to any suggestions and requirements you may have.

Did you already try to build it with distribution-provided tools only?

Christoph

---

From: Smolkin Grigory <[email-masked]>
Date: Thu, 13 Mar 2025 18:29:40 +0300

>thanks for the suggestion!

Hi!

>Did you already try to build it with distribution-provided tools only?

Yes, but unfortunately not all our dependencies are available in
standart distributions or have required versions.

>Christoph

Can we use cargo vendor?
https://doc.rust-lang.org/cargo/commands/cargo-vendor.html

We can pack all rust-dependencies in separate tarball.
That way it will be possible to build packages with single unified
behavior for all systems using the same sources.
It will be much easier to support and debug.
Thank you for your help!

---

From: Bradford Boyle <[email-masked]>
Date: Fri, 14 Mar 2025 20:38:56 -0700

> >> Would it be acceptable to install the compiler from https://rustup.rs/

My understanding is that Debian policy does not permit downloading
during the build [0].

> That way it will be possible to build packages with single unified behavior for all systems using the same sources.

According to this post [1] on the debian-rust mailing list, "vendoring
should be avoided unless there is a very good reason not to". The Debian
Rust packaging team has a pretty comprehensive guide [2] and it looks
like they have tooling to help assist with the packaging process.

-- Bradford

[0]: https://lists.debian.org/debian-devel/2020/12/msg00215.html
[1]: https://lists.debian.org/debian-rust/2024/11/msg00029.html
[2]: https://salsa.debian.org/rust-team/debcargo-conf/blob/master/README.rst

---

From: Smolkin Grigory <[email-masked]>
Date: Sun, 16 Mar 2025 14:32:39 +0700

>My understanding is that Debian policy >does not permit downloading
>during the build [0].

during package building?
during the build [0].

Ok, I suppose we have to live with distribution compiler. Though, it may
make some old systems without rust 1.70.0 unsupportable.

>> According to this post [1] on the debian-rust mailing list, "vendoring
should be avoided unless there is a very good reason not to".
>> The Debian Rust packaging team has a pretty comprehensive guide [2] and
it looks like they have tooling to help assist with the packaging process.

I think we have a very good reason here - a lot of distributions of
different versions with different libversions. Even making it just to be
"compilable" would require tremendous effort, supporting it will be
unmanageable.

I see no good reason not to use vendoring in case of "multiple
distribution"-build process.
    1. It's a tarboll artifact, released with main project, under the same
release tag.
    2. It is reproducible and has public hash, so it can be verified.
    3. It allows local build, nothing has to be downloaded.
    4. Consistent binary behavior across multiple distributions.

---

From: Brian Cosgrove <[email-masked]>
Date: Sun, 16 Mar 2025 06:30:29 -0500

For such a new piece of infrastructure is there really a compelling reason
to support distributions older than Debian bookworm (released 3 years ago)?
Do you have any current use-cases for something older?

-- 
Brian Cosgrove

---

From: Smolkin Grigory <[email-masked]>
Date: Sun, 16 Mar 2025 20:23:26 +0700

> For such a new piece of infrastructure is there really a compelling
reason to support distributions older than Debian bookworm (released 3
years ago)? Do you have any current use-cases for something older?

Well, only for the sake of user-friendliness to the people on really old
distributions, if it will not come at the price of real pain in our
backsides. We ourselves use only ubuntu:22.04 for now.

And I'm sure that vendoring will be of great help here.

---

From: Smolkin Grigory <[email-masked]>
Date: Wed, 19 Mar 2025 12:39:31 +0700

So, is it OK for you if we proceed with "debian/" based on vendor tarball?

Tarball itself looks like this (in assets)
https://github.com/ozontech/pg_doorman/releases/tag/v1.7.9

---

From: Christoph Berg <[email-masked]>
Date: Wed, 19 Mar 2025 12:04:28 +0100

Re: Smolkin Grigory
> https://github.com/ozontech/pg_doorman/releases/tag/v1.7.9

Note that debian/copyright needs to cover everything shipped,
including anything "vendored".

Christoph

---

From: Smolkin Grigory <[email-masked]>
Date: Fri, 21 Mar 2025 23:19:17 +0700

Re:
> Note that debian/copyright needs to cover everything shipped, including
anything "vendored

Thanks for pointing that out.

https://github.com/ozontech/pg_doorman/releases/download/v1.8.0/vendor-licenses.txt

Will that be acceptable? We can now generate debian/copyright from cargo
meta.

---

From: Christoph Berg <[email-masked]>
Date: Tue, 25 Mar 2025 16:14:34 +0100

Re: Smolkin Grigory
> Will that be acceptable? We can now generate debian/copyright from cargo

(Fwiw, I do not have the time to drive this forward myself, sorry.)

Christoph

---

From: Smolkin Grigory <[email-masked]>
Date: Tue, 25 Mar 2025 23:48:11 +0700

> Fwiw, I do not have the time to drive this forward myself, sorry.
>

But we've never even considered to burden someone with this task. Sorry if
I have accidently imparted such an impression, it was never may intention.

We will make all debian/* stuff by ourselves, we just want to make sure,
that we working in the right direction, in accordance with community
policies and customs.