Skip to content

fix: ensure file type bit is set for rpm bundle#5459

Merged
jkelleyrtp merged 1 commit intoDioxusLabs:mainfrom
acrilique:fix/rpm-fedora
Apr 7, 2026
Merged

fix: ensure file type bit is set for rpm bundle#5459
jkelleyrtp merged 1 commit intoDioxusLabs:mainfrom
acrilique:fix/rpm-fedora

Conversation

@acrilique
Copy link
Copy Markdown
Contributor

TLDR: By using the permissions() method of FileOptionsBuilder (which was added in version 0.20.0 of the rpm crate) instead of the mode() method, we fix a bug where newer versions of rpm (the package, not the crate) would fail when installing the bundle.


The generated rpm files failed to install in fedora 43:

>>> [RPM] unpacking of archive failed at file /usr/bin/pino;69d538ca: cpio:
>>> Unpacking error: pino-0:0.2.2-1.x86_64

The issue seems to stem from lines of code that call rpm::FileOptionsBuilder::mode(), e.g.:

rpm::FileOptions::new(dest_bin).mode(0o755)

Which causes the files inside the bundle to lack the file type bit, for instance these are the files inside my rpm package:

./usr/bin/pino                                          mode=0o000755 
./usr/share/applications/pino.desktop                   mode=0o000644 
./usr/share/icons/hicolor/128x128/apps/pino.png         mode=0o000644 
./usr/share/icons/hicolor/256x256/apps/pino.png         mode=0o000644 

Assuming that this code was added to dioxus by copying code from tauri, I wondered why would tauri have that incorrect code. Turns out older versions of rpm (like version 4.18 which is in the ubuntu 24.04 packages repo) do not enforce this specific bit, and do not fail when it's not set. Fedora provides a much newer version (6.0.1 on my system) which must have added a check for that.

Conveniently enough, the rpm crate just added a rpm::FileOptionsBuilder::permissions() method which does exactly what mode should be doing according to our syntax. From docs.rs:

pub fn permissions(self, permissions: u16) -> Self

Set the permission bits for the file without changing the file type.
This is the preferred way to set permissions. Unlike mode(), you only need to provide the permission bits (e.g. 0o755) without the file type prefix.
Values greater than 0o7777 will be masked to fit.

So basically the issue is fixed if we bump the rpm crate version and replace all lines like:

rpm::FileOptions::new(dest_bin).mode(0o755)

with:

rpm::FileOptions::new(dest_bin).permissions(0o755)

@acrilique acrilique requested a review from a team as a code owner April 7, 2026 19:23
By using the `permissions()` method of `FileOptionsBuilder`,
which was added in version 0.20.0 of the `rpm` crate, we fix
a bug where newer versions of `rpm` (the package, not the
crate) would fail when installing the bundle.
Copy link
Copy Markdown
Member

@jkelleyrtp jkelleyrtp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@jkelleyrtp jkelleyrtp merged commit 610ee81 into DioxusLabs:main Apr 7, 2026
21 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants