"Transaction test error" with different packages

Ask Fedora Ask in English
1

Hi, I recently tried to install Bitwarden and Notesnook using the rpm files provided on their websites.

Once I install one I cannot install the other.

I have seen this problem when someone upgrades the same package to different versions, but not with different packages.

I would appreciate it if you could help me, here is my terminal:

~/Downloads
❯ sudo dnf install Bitwarden-2023.1.1-x86_64.rpm
Last metadata expiration check: 1:41:49 ago on Mon 30 Jan 2023 10:21:30 AM EST.
Dependencies resolved.
===============================================================================================
 Package              Architecture      Version                  Repository               Size
===============================================================================================
Installing:
 bitwarden            x86_64            2023.1.1-1               @commandline             67 M

Transaction Summary
===============================================================================================
Install  1 Package

Total size: 67 M
Installed size: 248 M
Is this ok [y/N]: y
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Error: Transaction test error:
  file /usr/lib/.build-id/cb/dc9db5fec0e6129bddcb0c282be98be4c6966e from install of bitwarden-2023.1.1-1.x86_64 conflicts with file from package Notesnook-2.4.0-1.x86_64
2

Those are packages from different 3rd party repos and they are trying to install/overwrite the same file which conflicts.

Packages from within fedora are tested to not have those conflicts, but that cannot be said for packages from 3rd party repos.

It is up to the packager to manage conflicts and apparently they did not for those 2 apps.

2 Likes
3

Both of these packages bundle Electron. Apparently, the chrome-sandbox binary in both packages are exactly the same, and have the same build ID.

Inspecting the files in question:

$ rpm -qplv Bitwarden-2023.1.1-x86_64.rpm | grep dc9
lrwxrwxrwx    1 root     root                       40 Jan 13 21:33 /usr/lib/.build-id/cb/dc9db5fec0e6129bddcb0c282be98be4c6966e -> ../../../../opt/Bitwarden/chrome-sandbox
$ rpm -qplv notesnook_linux_x86_64.rpm | grep dc9
lrwxrwxrwx    1 root     root                       40 Jan 30 22:41 /usr/lib/.build-id/cb/dc9db5fec0e6129bddcb0c282be98be4c6966e -> ../../../../opt/Notesnook/chrome-sandbox

dnf will not allow you to install packages with conflicting files. It’s possible to force install the 2nd package using rpm which operates at a lower level than dnf, but please note:

  • Do so at your own risk.

  • Never do this without first checking the contents of the package you’re about to install. This time it will only overwrite this 1 build-id file. Don’t assume it’s the same next time, even if it’s just an update to the same package.

    You can list package contents using rpm -qpl <file>.

  • It will be missing from your dnf transaction history. dnf history will not have any record of you installing this package (although it will still show as an installed package).

To force install a package with conflicting files:

# rpm -i --replacefiles ./Bitwarden-2023.1.1-x86_64.rpm
1 Like
4

As for Bitwarden, just get it from here:

1 Like
5

It’s good to let people know that it’s there - for what it’s worth, the more paranoid among us might worry about getting something like Bitwarden from an unofficial source, like that Flatpak…I just don’t know enough about code review to know how to personally validate the integrity of packages like that, so I end up sticking with what I can get direct from the developer even if it’s a less preferable format.

2 Likes
6

Here is how the flatpak is built:

1 Like
7

Thanks! I guess my thought is, I think I understand what is going on there, but I don’t “know” that I’m assessing that correctly to be an unadulterated repackaging of what the Bitwarden folks themselves would publish (e.g. what is com.bitwarden.desktop/flathub.json at master · flathub/com.bitwarden.desktop · GitHub - looks like it would pull in other files)?

Probably just education needed on my part, but just sharing one of the challenges for me as a novice - needing to understand more of how the underlying code comes together to feel like I can logically explain to myself why the flatpak should inherit the trust of the Bitwarden code, rather than the trust of the flathub contributors.