Thread: Packages for pg_doorman
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:
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!
Re: Smolkin Grigory > 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 Hi, thanks for the suggestion! > Rust Dependency: pg_doorman is written in Rust and requires rustc version > 1.70.0 or higher. This would be the first PG-related package using rust, I would expect a lot of rust crate packages to be still missing. > However, we’re unsure if this version is available in all Debian-based > distributions via their default package repositories. Debian stable has 1.63, unstable has 1.85. Ubuntu noble has 1.75. > 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? 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
>Re: Smolkin Grigory
>> 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
>
>Hi,
>thanks for the suggestion!
Hi!
>
>> Rust Dependency: pg_doorman is written in Rust and requires rustc version
>> 1.70.0 or higher.
>
>This would be the first PG-related package using rust, I would expect
>a lot of rust crate packages to be still missing.
>
>> However, we’re unsure if this version is available in all Debian-based
>> distributions via their default package repositories.
>
>Debian stable has 1.63, unstable has 1.85.
>Ubuntu noble has 1.75.
>
>
>
>> 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?
>
>
>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?
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!
ср, 12 мар. 2025 г., 16:43 Christoph Berg <myon@debian.org>:
Re: Smolkin Grigory
> 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
Hi,
thanks for the suggestion!
> Rust Dependency: pg_doorman is written in Rust and requires rustc version
> 1.70.0 or higher.
This would be the first PG-related package using rust, I would expect
a lot of rust crate packages to be still missing.
> However, we’re unsure if this version is available in all Debian-based
> distributions via their default package repositories.
Debian stable has 1.63, unstable has 1.85.
Ubuntu noble has 1.75.
> 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?
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
> >> Build Process: > >> Would it be acceptable to install the compiler from https://rustup.rs/ > >> during package building? My understanding is that Debian policy does not permit downloading during the build [0]. > > 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. 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
> Can we use cargo vendor?
>My understanding is that Debian policy >does not permit downloading
>during the build [0].
>Would it be acceptable to install the compiler from https://rustup.rs/ during package building?
>> My understanding is that Debian policy does not permit downloading
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.
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?
On Sun, Mar 16, 2025 at 4:17 AM Smolkin Grigory <smallkeen@gmail.com> wrote:
> Can we use cargo vendor?>My understanding is that Debian policy >does not permit downloading>during the build [0].>Would it be acceptable to install the compiler from https://rustup.rs/ during package building?>> My understanding is that Debian policy does not permit downloadingduring 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.
Brian Cosgrove
> 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.
So, is it OK for you if we proceed with "debian/" based on vendor tarball?
Tarball itself looks like this (in assets)
Re: Smolkin Grigory > 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 Note that debian/copyright needs to cover everything shipped, including anything "vendored". Christoph
Re:
> Note that debian/copyright needs to cover everything shipped, including anything "vendored
>Thanks for pointing that out.
Will that be acceptable? We can now generate debian/copyright from cargo meta.
Re: Smolkin Grigory > Will that be acceptable? We can now generate debian/copyright from cargo > meta. (Fwiw, I do not have the time to drive this forward myself, sorry.) Christoph
> 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.