Closed HeavenVolkoff closed 1 year ago
I can confirm the current locked FFMPEG version is available for Arch and this is just a issue to push to the latest.
myself and @fogodev discussed this the other day, and there's two repositories that must offer ffmpeg6 before we can attempt the update: brew
and debian/apt
it doesn't seem as though brew
has updated, at the time of writing
the compile-time logic you mention would be pretty cool, but i'm not even sure something such as that is possible (sadly)
the only solutions i can offer currently are: continue using ffmpeg-sys-next 6.x.x
locally, or downgrade ffmpeg back to 5.1.x.
both aren't the most practical, and i do apologise - i think we may just have to wait this one out.
the compile-time logic you mention would be pretty cool, but i'm not even sure something such as that is possible (sadly)
I did some research on the topic, and although I found that Cargo supports build scripts and dependency patching, these don't seem to provide a way to override a crate version based on a system library version.
In the worst case scenario, since everything in the repository is called through pnpm, it may be possible to write a simple script that patches the Cargo.toml file before calling the Rust compiler. It may not be elegant, but it should work. Alternatively, maybe it would be better to compiling a version of ffmpeg specifically for Spacedrive needs, especially considering that the situation with Windows and FFmpeg is also kinda flaky.
it does appear possible, but in hindsight i also don't think it would be a great idea (not in this situation anyway). a major version bump such as ffmpeg 5.1.x -> ffmpeg 6.0.0 is considered breaking by the rules of semantic versioning, and that also means we may have to update some of the code.
the above may not be the case for this instance, but it's bound to happen in the future. there's also nothing stopping archaic versions from being detected/used by a script, and ffmpeg versioning isn't directly 1:1 with ffmpeg-sys-next
- quite a few problems to overcome.
along with this, it means Spacedrive build reproducibility goes completely out of the window; i can forsee quite a few issues that'll come with that (e.g. something works for me on Fedora, but not you using Arch, all because our ffmpeg versions are changed on-the-fly).
Perhaps we can package as a flatpak/snap/appimage or otherwise bundle a known-compatible version of ffmpeg?
Perhaps we can package as a flatpak/snap/appimage or otherwise bundle a known-compatible version of ffmpeg?
This is the plan for release builds anyway, afaik - leaving it to our users to handle the installation of dependencies wouldn't be the best experience.
For the next guy who's not to comfortable with rust. The local quick fix solution is to: Change the references in both files below from 5.1.1 to 6.0.0 crates/ffmpeg/Cargo.toml core/Cargo.toml
This was solved in #697
Describe the bug
Hi,
Currently, compiling the desktop app in Arch Linux fails due to a newer version of
ffmpeg
being the only one available in the official repositories:This is due to a rust dependency:
ffmpeg-next
, which seems to only work with specific versions of ffmpeg. At this time, Spacedrive desktop app is tied to ffmpeg v5.1.1: https://github.com/spacedriveapp/spacedrive/blob/2e3c708db88a8979a8cc46897796c56366eada96/core/Cargo.toml#L74I tried to just update the version of the dependency in Cargo, and that solved the problem, as I was able to compile the desktop app. However, I decided against opening a PR with those changes, because this would probably break compiling in other distros and OSes. In my opinion, the best solution would be to implement some compile time logic to decide the version of the
ffmpeg-next
create according to the system's ffmpeg version. However, I am not well versed in rust, so I will leave this one to someone else (or until I learn enough rust to do it 😄)Here is the diff of my changes for anyone using Arch that is also having this problem:
Reproduction
CONTRIBUTING.md
until steppnpm desktop dev
pnpm desktop dev
fails due to create incompatibility with newer ffmpeg versionExpected behavior
pnpm desktop dev
successfully executes and all dependencies are correctly compliedPlatform and versions
Stack trace
Additional context
None