chore: Move rfd dependency to workspace

[kjarosh]

This makes sure there's only one version of rfd used and fixes Flatpak compilation issues.

error: checksum for `rfd v0.14.1` could not be calculated, but a checksum is listed in the existing lock file

this could be indicative of a few possible situations:

    * the source `registry `crates-io`` supports checksums,
      but was replaced with one that doesn't
    * the lock file is corrupt

unable to verify that `rfd v0.14.1` is the same as when the lockfile was generated

[torokati44]

If you want this to really stick, you could also add rfd to deny.toml, next to tracy-client and image.

[kjarosh]

I don't think it's an issue specific to rfd. I suspect any dependency defined two times (git + crates.io) with the same version will produce this error :/ Probably a bug in flatpak-builder-tools or in cargo.

[torokati44]

Would it make sense to add a Flatpak build check as a weekly CI run (like for the AMO Docker image), or not, because updates are done manually by us anyway, and any issues can be fixed immediately?

[kjarosh]

Would it make sense to add a Flatpak build check as a weekly CI run

I'll think about and maybe create a workflow, but in general I do not expect huge discrepancies in the build process, as Flatpak build is just cargo build, but offline.

[torokati44]

Flatpak build is just cargo build, but offline.

The "internal" Rust build may be, but isn't there some additional bells and whistles to turn the binary into an actual Flatpak? I meant more to check those parts, not necessarily what cargo does. But I'm not that familiar with how this sausage is made...

[kjarosh]

The "internal" Rust build may be, but isn't there some additional bells and whistles to turn the binary into an actual Flatpak? I meant more to check those parts, not necessarily what cargo does. But I'm not that familiar with how this sausage is made...

That is true, but unintuitively these bells and whistles are problematic to be tested here, as in case they need to be updated, the build will fail even if everything's okay.

Imagine that we move a .desktop file in upstream (so here), the path will also need to be changed downstream (Flathub), but if we just take the downstream as-is and replace sources, the build will fail because the path is not yet updated. Moreover, it cannot be updated unless we also update the version of upstream, so there's the chicken and egg problem.