Message-ID: <7e1f2552-82c3-40c6-baf1-ef65cfd0ac30@pgbackrest.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: pgsql-pkg-debian@lists.postgresql.org, pgsql-pkg-yum@lists.postgresql.org
From: David Steele <david@pgbackrest.org>
Subject: Migration of pgBackRest internal support tools to Rust.
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 15 Jul 2026 02:44:30 +0000 (UTC)
Archived-At: 
 <https://www.postgresql.org/message-id/7e1f2552-82c3-40c6-baf1-ef65cfd0ac30%40pgbackrest.org>
Precedence: bulk

Greetings Packagers,

I'm considering migrating the pgBackRest support tools to Rust and I'd 
appreciate any feedback on how this would affect packaging.

To be clear, the pgBackRest binary itself would stay in C, so this only 
affects the internal build and support tooling.

We have three internal tools that support pgBackRest:

- Code generation (/src/build), which is written entirely in C and is 
the simplest of the three. It reads various YAML files and does code 
generation for configuration, help, errors, and support for various 
PostgreSQL versions. Most of the generated code is checked in with a 
couple of exceptions:

     - src/command/help/help.auto.c.inc - this is compressed binary data 
for the command line help. It is not checked in because even small 
changes to the help tend to rewrite the entire file.

     - src/postgres/interface.auto.c.inc - this defines the interface to 
each supported version of PostgreSQL using data structures pulled from 
PostgreSQL and macros that define functions. It is low churn but is not 
that useful for review purposes so it is not checked in, but it could be.

All packages currently run code generation since it is baked into the 
meson build. So if the generator moves to Rust, every package would need 
Rust at build time unless the generated files are shipped with the release.

- Second is doc generation (/doc). This is about 1/3 C and the rest is 
still in Perl. The code builds and executes the user guide and other 
source XML and outputs HTML, markdown, and man pages. Most of the 
complexity is in the Perl code but none of it is too complicated. The 
Debian package uses the doc generator.

- Last is the test harness (/test), which is also about 1/3 C and the 
rest in Perl. In addition to running tests this code manages code 
generation, linting, container builds, code formatting, etc. The unit 
and integration tests have to stay in C but the harness can be in any 
language. I'm not aware of any packages that run our tests, though.

Rather than complete the migration from Perl to C, I would prefer to 
just migrate all of it to Rust. Rust is a powerful language with rich 
libraries that would make my life much easier and in the long run save 
time. I prototyped migrating the test harness C code to Rust and it 
looks pretty good.

The easiest thing would be for the packagers to provide Rust in the 
build environment so code generation can run and packages can build 
documentation or run tests as they please, but my understanding is that 
Rust is problematic for some packages, and even where it is supported 
the selection of crates would be limited with potential version issues 
for older distros.

My proposal is to provide the files that are currently generated at 
build time (html documentation, man pages, help.auto.c.inc, 
interface.auto.c.inc) in each release either by checking them into the 
repo with each release or by providing a dist tarball that adds the 
generated files. The former option would require no changes for packages 
while the latter would require pointing at a new tarball. Either way, no 
new dependencies are required and in fact a few could be dropped, e.g. 
Perl and libyaml.

Would either approach cause problems for your packaging, and do you have 
a preference? Please let me know if you see any other issues.

Thanks,
-David