Hi Rust packagers,
this is my first time attempting to package a Rust package in Fedora.
My end goal is to package Evolution EteSync, the EteSync plugin for Evolution: https://gitlab.gnome.org/GNOME/evolution-etesync
Evolution EteSync requires packaging libetebase (https://github.com/etesync/libetebase), a C client library for Etebase which basically wraps the Rust client library etebase-rs (https://github.com/etesync/etebase-rs) and exposes a C interface on top of it.
So, I first looked into packaging etebase-rs crate and its dependencies (that are not already packaged).
Running `cargo tree` gives a scarily large dependency tree. If I limit it to direct dependencies (i.e. `cargo tree --depth 1`), the number becomes more manageable:
etebase v0.6.1 (/home/tadej/Code/etebase-rs) ├── ed25519 v1.5.3 ├── openssl v0.10.73 ├── openssl-sys v0.9.109 │ [build-dependencies] ├── remove_dir_all v0.8.4 ├── reqwest v0.11.27 ├── rmp-serde v1.3.0 ├── serde v1.0.219 ├── serde_bytes v0.11.17 ├── serde_repr v0.1.20 (proc-macro) ├── sodiumoxide v0.2.7 └── url v2.5.4 [build-dependencies] └── cc v1.2.27
I have a few questions here:
1. Is there a tool that would check Fedora's dist-git and give you an overview of which dependencies are already packaged (and at what versions)?
2. How to handle dependencies' versions? - For example, the current ed25519 version in Fedora is 2.2.3, but etebase-rs requires version >=1.5.3 and <1.6.0. - A 'safe' approach seems to require adding an additional "compat" version for each dependency that is not satisfied? - A 'quick' approach would be to try patching Cargo.toml with the versions that are provided in Fedora? - Which approach to take?
Thanks for your advice and best regards, Tadej
On Fri, Jun 13, 2025 at 10:10 AM Tadej Janež via Rust rust@lists.fedoraproject.org wrote:
Hi Rust packagers,
this is my first time attempting to package a Rust package in Fedora.
My end goal is to package Evolution EteSync, the EteSync plugin for Evolution: https://gitlab.gnome.org/GNOME/evolution-etesync
Evolution EteSync requires packaging libetebase (https://github.com/etesync/libetebase), a C client library for Etebase which basically wraps the Rust client library etebase-rs (https://github.com/etesync/etebase-rs) and exposes a C interface on top of it.
So, I first looked into packaging etebase-rs crate and its dependencies (that are not already packaged).
Running `cargo tree` gives a scarily large dependency tree. If I limit it to direct dependencies (i.e. `cargo tree --depth 1`), the number becomes more manageable:
etebase v0.6.1 (/home/tadej/Code/etebase-rs) ├── ed25519 v1.5.3 ├── openssl v0.10.73 ├── openssl-sys v0.9.109 │ [build-dependencies] ├── remove_dir_all v0.8.4 ├── reqwest v0.11.27 ├── rmp-serde v1.3.0 ├── serde v1.0.219 ├── serde_bytes v0.11.17 ├── serde_repr v0.1.20 (proc-macro) ├── sodiumoxide v0.2.7 └── url v2.5.4 [build-dependencies] └── cc v1.2.27
I have a few questions here:
- Is there a tool that would check Fedora's dist-git and give you an
overview of which dependencies are already packaged (and at what versions)?
My strategy has been to use rust2rpm to make the main package and try to build it in Mock, then paste the listed missing crate Provides in a "dnf repoquery" command. You can give it multiple --whatprovides arguments, and this search will include all API-compat crates so you'll see the different versions available. For example, this will find both the 1.0 and 0.7 API packages for remove_dir_all:
dnf \ --disablerepo='*' \ --enablerepo=rawhide \ --quiet \ repoquery \ --latest-limit=1 \ --whatprovides='crate(remove_dir_all)' \ --whatprovides='crate(serde)' \ --whatprovides='crate(this-doesnt-exist)'
- How to handle dependencies' versions?
- For example, the current ed25519 version in Fedora is 2.2.3, but
etebase-rs requires version >=1.5.3 and <1.6.0.
- A 'safe' approach seems to require adding an additional "compat"
version for each dependency that is not satisfied?
- A 'quick' approach would be to try patching Cargo.toml with the
versions that are provided in Fedora?
- Which approach to take?
The guidelines say to prefer patching to update to the latest crate versions in Fedora when possible (and ideally send the update upstream), but adding compat packages for older APIs is allowed when that's not feasible.
https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_packaging_m...
Thanks.
David
On Sat, 2025-06-14 at 08:17 -0400, David Michael via Rust wrote:
I have a few questions here:
- Is there a tool that would check Fedora's dist-git and give you
an overview of which dependencies are already packaged (and at what versions)?
My strategy has been to use rust2rpm to make the main package and try to build it in Mock, then paste the listed missing crate Provides in a "dnf repoquery" command. You can give it multiple --whatprovides arguments, and this search will include all API-compat crates so you'll see the different versions available. For example, this will find both the 1.0 and 0.7 API packages for remove_dir_all:
dnf \ --disablerepo='*' \ --enablerepo=rawhide \ --quiet \ repoquery \ --latest-limit=1 \ --whatprovides='crate(remove_dir_all)' \ --whatprovides='crate(serde)' \ --whatprovides='crate(this-doesnt-exist)'
Thanks, this is helpful (even if it feels a bit more "manual" than what I would have hoped).
- How to handle dependencies' versions?
- For example, the current ed25519 version in Fedora is 2.2.3, but etebase-rs requires version >=1.5.3 and <1.6.0. - A 'safe' approach seems to require adding an additional "compat" version for each dependency that is not satisfied? - A 'quick' approach would be to try patching Cargo.toml with the versions that are provided in Fedora? - Which approach to take?
The guidelines say to prefer patching to update to the latest crate versions in Fedora when possible (and ideally send the update upstream), but adding compat packages for older APIs is allowed when that's not feasible.
https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_packaging_m...
Thanks for the pointer!
Regards, Tadej
Hi,
- Is there a tool that would check Fedora's dist-git and give you
an overview of which dependencies are already packaged (and at what versions)?
My strategy has been to use rust2rpm to make the main package and try to build it in Mock, then paste the listed missing crate Provides in a "dnf repoquery" command. You can give it multiple --whatprovides arguments, and this search will include all API-compat crates so you'll see the different versions available. For example, this will find both the 1.0 and 0.7 API packages for remove_dir_all:
dnf \ --disablerepo='*' \ --enablerepo=rawhide \ --quiet \ repoquery \ --latest-limit=1 \ --whatprovides='crate(remove_dir_all)' \ --whatprovides='crate(serde)' \ --whatprovides='crate(this-doesnt-exist)'
Thanks, this is helpful (even if it feels a bit more "manual" than what I would have hoped).
cargo2rpm (used by the rpm macros) is useful too and it is possible to automate things with little scripting around that, /me uses the script below to install build dependencies.
take care, Gerd
--------------------------- cut here ----------------------- #!/usr/bin/python3 # # Run cargo2rpm on Cargo.toml in current directory to get rpm # build dependencies. Them go try install the rpms. # import sys import subprocess
def main(): cmdline = [ 'cargo2rpm', '--path', 'Cargo.toml', 'buildrequires' ] rc = subprocess.run(cmdline, capture_output = True) if rc.returncode: print(f'# ERROR: returncode is {rc.returncode}') print(rc.stderr.decode()) return rc.returncode
rpms = rc.stdout.decode().strip().split('\n'); cmdline = [ 'sudo', 'dnf', 'install', '--skip-unavailable', *rpms ] print(cmdline) subprocess.run(cmdline)
if __name__ == '__main__': sys.exit(main())
On Tue, Jun 17, 2025 at 12:10 PM Gerd Hoffmann via Rust rust@lists.fedoraproject.org wrote:
Hi,
- Is there a tool that would check Fedora's dist-git and give you
an overview of which dependencies are already packaged (and at what versions)?
My strategy has been to use rust2rpm to make the main package and try to build it in Mock, then paste the listed missing crate Provides in a "dnf repoquery" command. You can give it multiple --whatprovides arguments, and this search will include all API-compat crates so you'll see the different versions available. For example, this will find both the 1.0 and 0.7 API packages for remove_dir_all:
dnf \ --disablerepo='*' \ --enablerepo=rawhide \ --quiet \ repoquery \ --latest-limit=1 \ --whatprovides='crate(remove_dir_all)' \ --whatprovides='crate(serde)' \ --whatprovides='crate(this-doesnt-exist)'
Thanks, this is helpful (even if it feels a bit more "manual" than what I would have hoped).
cargo2rpm (used by the rpm macros) is useful too and it is possible to automate things with little scripting around that, /me uses the script below to install build dependencies.
I would strongly recommend not to do this (i.e. install rust-*-devel packages on your host system). Building Rust packages outside of mock is not a use case that we can reasonably support.
Fabio
On Fri, Jun 13, 2025, 16:10 Tadej Janež via Rust < rust@lists.fedoraproject.org> wrote:
Hi Rust packagers,
this is my first time attempting to package a Rust package in Fedora.
My end goal is to package Evolution EteSync, the EteSync plugin for Evolution: https://gitlab.gnome.org/GNOME/evolution-etesync
Evolution EteSync requires packaging libetebase (https://github.com/etesync/libetebase), a C client library for Etebase which basically wraps the Rust client library etebase-rs (https://github.com/etesync/etebase-rs) and exposes a C interface on top of it.
So, I first looked into packaging etebase-rs crate and its dependencies (that are not already packaged).
Running `cargo tree` gives a scarily large dependency tree.
Scarily large is relative ;)
If I limit it to direct dependencies (i.e. `cargo tree --depth 1`), the
number becomes more manageable:
etebase v0.6.1 (/home/tadej/Code/etebase-rs) ├── ed25519 v1.5.3 ├── openssl v0.10.73 ├── openssl-sys v0.9.109 │ [build-dependencies] ├── remove_dir_all v0.8.4 ├── reqwest v0.11.27 ├── rmp-serde v1.3.0 ├── serde v1.0.219 ├── serde_bytes v0.11.17 ├── serde_repr v0.1.20 (proc-macro) ├── sodiumoxide v0.2.7 └── url v2.5.4 [build-dependencies] └── cc v1.2.27
The only problematic one I see here is sodiumoxide. This project has been abandoned and probably really shouldn't be used any longer ... all others are already packaged for Fedora as far as I can tell.
I have a few questions here:
- Is there a tool that would check Fedora's dist-git and give you an
overview of which dependencies are already packaged (and at what versions)?
Yes, you can use cargo-rpmstatus for this purpose.
- How to handle dependencies' versions?
- For example, the current ed25519 version in Fedora is 2.2.3, but
etebase-rs requires version >=1.5.3 and <1.6.0.
- A 'safe' approach seems to require adding an additional "compat"
version for each dependency that is not satisfied?
- A 'quick' approach would be to try patching Cargo.toml with the
versions that are provided in Fedora?
- Which approach to take?
It depends. If the update is safe and easy to do (for example, no breaking API changes that affect the project), then bumping the dependency is preferred.
Thanks for your advice and best regards, Tadej
Fabio
On Sat, 2025-06-14 at 18:30 +0200, Fabio Valentini via Rust wrote:
On Fri, Jun 13, 2025, 16:10 Tadej Janež via Rust rust@lists.fedoraproject.org wrote:
Hi Rust packagers,
this is my first time attempting to package a Rust package in Fedora.
My end goal is to package Evolution EteSync, the EteSync plugin for Evolution: https://gitlab.gnome.org/GNOME/evolution-etesync
Evolution EteSync requires packaging libetebase (https://github.com/etesync/libetebase), a C client library for Etebase which basically wraps the Rust client library etebase-rs (https://github.com/etesync/etebase-rs) and exposes a C interface on top of it.
So, I first looked into packaging etebase-rs crate and its dependencies (that are not already packaged).
Running `cargo tree` gives a scarily large dependency tree.
Scarily large is relative ;)
He he, that is true :).
If I limit it to direct dependencies (i.e. `cargo tree --depth 1`), the number becomes more manageable:
etebase v0.6.1 (/home/tadej/Code/etebase-rs) ├── ed25519 v1.5.3 ├── openssl v0.10.73 ├── openssl-sys v0.9.109 │ [build-dependencies] ├── remove_dir_all v0.8.4 ├── reqwest v0.11.27 ├── rmp-serde v1.3.0 ├── serde v1.0.219 ├── serde_bytes v0.11.17 ├── serde_repr v0.1.20 (proc-macro) ├── sodiumoxide v0.2.7 └── url v2.5.4 [build-dependencies] └── cc v1.2.27
The only problematic one I see here is sodiumoxide. This project has been abandoned and probably really shouldn't be used any longer ...
Indeed, the GitHub repository has been archived in Sep 2022.
Do you perhaps have any suggestions on alternative Rust libraries I could recommend to the upstream?
all others are already packaged for Fedora as far as I can tell.
Correct. They might not have the exact matching version, but these could be reviewed and patched one by one.
I have a few questions here:
- Is there a tool that would check Fedora's dist-git and give you
an overview of which dependencies are already packaged (and at what versions)?
Yes, you can use cargo-rpmstatus for this purpose.
Is it packaged in Fedora? I was curious why it is not mentioned anywhere :)
- How to handle dependencies' versions?
- For example, the current ed25519 version in Fedora is 2.2.3, but etebase-rs requires version >=1.5.3 and <1.6.0. - A 'safe' approach seems to require adding an additional "compat" version for each dependency that is not satisfied? - A 'quick' approach would be to try patching Cargo.toml with the versions that are provided in Fedora? - Which approach to take?
It depends. If the update is safe and easy to do (for example, no breaking API changes that affect the project), then bumping the dependency is preferred.
Thanks for the advice.
Regards, Tadej
On Mon, Jun 16, 2025 at 10:41 PM Tadej Janež tadej.j@nez.si wrote:
The only problematic one I see here is sodiumoxide. This project has been abandoned and probably really shouldn't be used any longer ...
Indeed, the GitHub repository has been archived in Sep 2022.
Do you perhaps have any suggestions on alternative Rust libraries I could recommend to the upstream?
It depends on which functionality from libsodium they need. They already depend on OpenSSL, I would just use that if possible.
If OpenSSL doesn't provide everything they need, the RustCrypto project provides implementations for a lot of things: https://github.com/RustCrypto
Yes, you can use cargo-rpmstatus for this purpose.
Is it packaged in Fedora? I was curious why it is not mentioned anywhere :)
A package for it is being worked on: https://bugzilla.redhat.com/show_bug.cgi?id=2326609
It's not currently mentioned anywhere because 1) it's not packaged yet and 2) it has limitations and sometimes gives wrong results.
Fabio
On Tue, 2025-06-17 at 15:58 +0200, Fabio Valentini via Rust wrote:
On Mon, Jun 16, 2025 at 10:41 PM Tadej Janež tadej.j@nez.si wrote:
The only problematic one I see here is sodiumoxide. This project has been abandoned and probably really shouldn't be used any longer ...
Indeed, the GitHub repository has been archived in Sep 2022.
Do you perhaps have any suggestions on alternative Rust libraries I could recommend to the upstream?
It depends on which functionality from libsodium they need. They already depend on OpenSSL, I would just use that if possible.
If OpenSSL doesn't provide everything they need, the RustCrypto project provides implementations for a lot of things: https://github.com/RustCrypto
I discovered that the upstream issue report about sodiumoxide being deprecated dates back to Nov 2021: https://github.com/etesync/etebase-rs/issues/24
I've bumped it by commenting on the Fedora packaging situation but I don't have high hopes that it would be resolved any time soon.
That issue also mentioned openSUSE packaging efforts and I discovered that they have libetebase (C API interface for the Rust etebase-rs crate) packaged: https://build.opensuse.org/projects/openSUSE:Factory/packages/libetebase/
Can you figure out from the SPEC file how they handled the Rust part? I expected libetebase to depend on etebase-rs but I don't see that? https://build.opensuse.org/projects/openSUSE:Factory/packages/libetebase/fil...
Yes, you can use cargo-rpmstatus for this purpose.
Is it packaged in Fedora? I was curious why it is not mentioned anywhere :)
A package for it is being worked on: https://bugzilla.redhat.com/show_bug.cgi?id=2326609
It's not currently mentioned anywhere because 1) it's not packaged yet and 2) it has limitations and sometimes gives wrong results.
Nice. I hope it will be reviewed and available in Fedora soon!
Regards, Tadej
On Tue, Jun 17, 2025 at 4:43 PM Tadej Janež via Rust rust@lists.fedoraproject.org wrote:
On Tue, 2025-06-17 at 15:58 +0200, Fabio Valentini via Rust wrote:
On Mon, Jun 16, 2025 at 10:41 PM Tadej Janež tadej.j@nez.si wrote:
The only problematic one I see here is sodiumoxide. This project has been abandoned and probably really shouldn't be used any longer ...
Indeed, the GitHub repository has been archived in Sep 2022.
Do you perhaps have any suggestions on alternative Rust libraries I could recommend to the upstream?
It depends on which functionality from libsodium they need. They already depend on OpenSSL, I would just use that if possible.
If OpenSSL doesn't provide everything they need, the RustCrypto project provides implementations for a lot of things: https://github.com/RustCrypto
I discovered that the upstream issue report about sodiumoxide being deprecated dates back to Nov 2021: https://github.com/etesync/etebase-rs/issues/24
I've bumped it by commenting on the Fedora packaging situation but I don't have high hopes that it would be resolved any time soon.
Thanks!
That issue also mentioned openSUSE packaging efforts and I discovered that they have libetebase (C API interface for the Rust etebase-rs crate) packaged: https://build.opensuse.org/projects/openSUSE:Factory/packages/libetebase/
Can you figure out from the SPEC file how they handled the Rust part? I expected libetebase to depend on etebase-rs but I don't see that? https://build.opensuse.org/projects/openSUSE:Factory/packages/libetebase/fil...
OpenSUSE packaging for Rust applications is quite different from what we do by default in Fedora, you cannot really compare them. From what I can tell, they just ignored the warnings about the libsodium bindings being unmaintained that were raised during the security audit and just included them anyway.
Fabio
On Tue, 2025-06-17 at 16:50 +0200, Fabio Valentini via Rust wrote:
On Tue, Jun 17, 2025 at 4:43 PM Tadej Janež via Rust rust@lists.fedoraproject.org wrote:
That issue also mentioned openSUSE packaging efforts and I discovered that they have libetebase (C API interface for the Rust etebase-rs crate) packaged: https://build.opensuse.org/projects/openSUSE:Factory/packages/libetebase/
Can you figure out from the SPEC file how they handled the Rust part? I expected libetebase to depend on etebase-rs but I don't see that? https://build.opensuse.org/projects/openSUSE:Factory/packages/libetebase/fil...
OpenSUSE packaging for Rust applications is quite different from what we do by default in Fedora, you cannot really compare them. From what I can tell, they just ignored the warnings about the libsodium bindings being unmaintained that were raised during the security audit and just included them anyway.
Ok, I see.
To circle back to the etebase-rs packaging in Fedora. Am I right in assuming that unless it replaces the sodiumoxide dependency, it doesn't make sense to attempt to package it for Fedora?
Regards, Tadej
On Tue, Jun 17, 2025 at 6:14 PM Tadej Janež via Rust rust@lists.fedoraproject.org wrote:
On Tue, 2025-06-17 at 16:50 +0200, Fabio Valentini via Rust wrote:
On Tue, Jun 17, 2025 at 4:43 PM Tadej Janež via Rust rust@lists.fedoraproject.org wrote:
That issue also mentioned openSUSE packaging efforts and I discovered that they have libetebase (C API interface for the Rust etebase-rs crate) packaged: https://build.opensuse.org/projects/openSUSE:Factory/packages/libetebase/
Can you figure out from the SPEC file how they handled the Rust part? I expected libetebase to depend on etebase-rs but I don't see that? https://build.opensuse.org/projects/openSUSE:Factory/packages/libetebase/fil...
OpenSUSE packaging for Rust applications is quite different from what we do by default in Fedora, you cannot really compare them. From what I can tell, they just ignored the warnings about the libsodium bindings being unmaintained that were raised during the security audit and just included them anyway.
Ok, I see.
To circle back to the etebase-rs packaging in Fedora. Am I right in assuming that unless it replaces the sodiumoxide dependency, it doesn't make sense to attempt to package it for Fedora?
I would say yes.
The package review request for the sodiumoxide crate has been open for years (since 2022!), and we haven't even gotten to a point where it builds and tests run successfully on all our architectures: https://bugzilla.redhat.com/show_bug.cgi?id=2121490
And the project has been archived since then, so I'd much rather not package an abandoned cryptography library.
Fabio
On Wed, 2025-06-18 at 12:17 +0200, Fabio Valentini via Rust wrote:
On Tue, Jun 17, 2025 at 6:14 PM Tadej Janež via Rust rust@lists.fedoraproject.org wrote:
On Tue, 2025-06-17 at 16:50 +0200, Fabio Valentini via Rust wrote:
On Tue, Jun 17, 2025 at 4:43 PM Tadej Janež via Rust rust@lists.fedoraproject.org wrote:
That issue also mentioned openSUSE packaging efforts and I discovered that they have libetebase (C API interface for the Rust etebase-rs crate) packaged: https://build.opensuse.org/projects/openSUSE:Factory/packages/libetebase/
Can you figure out from the SPEC file how they handled the Rust part? I expected libetebase to depend on etebase-rs but I don't see that? https://build.opensuse.org/projects/openSUSE:Factory/packages/libetebase/fil...
OpenSUSE packaging for Rust applications is quite different from what we do by default in Fedora, you cannot really compare them. From what I can tell, they just ignored the warnings about the libsodium bindings being unmaintained that were raised during the security audit and just included them anyway.
Ok, I see.
To circle back to the etebase-rs packaging in Fedora. Am I right in assuming that unless it replaces the sodiumoxide dependency, it doesn't make sense to attempt to package it for Fedora?
I would say yes.
I agree.
The package review request for the sodiumoxide crate has been open for years (since 2022!), and we haven't even gotten to a point where it builds and tests run successfully on all our architectures: https://bugzilla.redhat.com/show_bug.cgi?id=2121490
And the project has been archived since then, so I'd much rather not package an abandoned cryptography library.
I've read through that review request and I agree with you and Simo Sorce that it is best not to package sodiumoxide.
Regards, Tadej