Skip to content

Conversation

@mmdbalkhi
Copy link
Contributor

Testing the changes

  • I tested the changes in this PR: YES

New package

Local build testing

  • I built this PR locally for my native architecture, x86_64-glibc
  • I built this PR locally for these architectures (if supported. mark crossbuilds):
    • arch64-musl
    • armv7l
    • armv6l-musl

cc: @classabbyamp

Copy link
Member

@classabbyamp classabbyamp left a comment

Choose a reason for hiding this comment

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

libswresample7>=${version}_${revision}"
short_desc+=" - development files"
conflicts="ffmpeg-devel"
replaces="ffmpeg-devel>=0"
Copy link
Member

Choose a reason for hiding this comment

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

needs to conflict/replace with other ffmpeg*-devel too

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is this necessary for the other subpkgs as well? The build of the ffplay7 package failed due to the conflict field.

...
ffplay7_package() {
		short_desc="Simple video player using FFmpeg and SDL2"
+		conflicts="ffplay*"
+		replaces="ffplay*>0"
		pkg_install() {
				vmove usr/bin/ffplay
				vmove "usr/share/man/man1/ffplay*"
		}
}

Copy link
Contributor

Choose a reason for hiding this comment

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

think ffplay is fine but ffmpeg6-devel exist

Copy link
Contributor

Choose a reason for hiding this comment

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

may need to disable ffplay in 6...or replace 6 entirely idk, depends how many deps build with 7 fine?

Copy link
Contributor Author

@mmdbalkhi mmdbalkhi Jan 4, 2025

Choose a reason for hiding this comment

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

may need to disable ffplay in 6...or replace 6 entirely

Why are you considering disabling ffplay in 6? Is there a specific reason behind it?

Copy link
Contributor

Choose a reason for hiding this comment

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

7 is newer so the binary ffmpeg/ffplay may as well be 7 on the system. only a few thing use the binaries directly instead of the libraries. ill post my branch iaf.

basically:

  • add depends to ffplay7 here
  • ffmpeg and ffmpeg6 need the conflict for devel packages and a revbumped
  • ffplay6 becomes meta pkg like ffmpeg's ffplay is

@classabbyamp classabbyamp added the new-package This PR adds a new package label Jan 4, 2025
@zlice
Copy link
Contributor

zlice commented Jan 4, 2025

will try to build to cluster-f of dep packages tonight unless you have mmdbalkhi

@zlice
Copy link
Contributor

zlice commented Jan 4, 2025

@classabbyamp is there anything bad with #51496 ? just makes this a pita the keep flipping between onevpl and libvpl

@classabbyamp
Copy link
Member

ask the maintainer of onevpl, not me

@zlice
Copy link
Contributor

zlice commented Jan 4, 2025

https://github.com/zlice/void-packages/tree/ffmpeg7 this is dirty because of libvpl as mentioned, some revbumps and stuff are off

should be 84 packages to test ffmpeg7-devel

@zlice
Copy link
Contributor

zlice commented Jan 5, 2025

These didn't build. Some probably have patches like xine-lib did

builds fine

needs work

  • pcsx2 - 2.20 is out but ive seen void builds as WIP before

  • mixxx - 2.5.0 ? mixxx: update to 2.5.0 #53868 (qt6)

  • blender (other PRs in the works right now)

big

  • openmw - too much to patch, easier to just wait for release (mwsound and osg-ffmpeg-videoplayer dirs)
  • qt5-webengine
  • qt6-pdf
  • kodi (next version being worked on)

@ahesford
Copy link
Member

ahesford commented Jan 6, 2025

Now that the vast majority of our packages build against ffmpeg6, I think it's time to bite the bullet:

  • Move ffmpeg -> ffmpeg4; rebuild all packages that still cannot be moved to newer ffmpeg.
  • Move ffmpeg6 -> ffmpeg with a simultaneous bump to v7.

We want to avoid an endless string of versioned ffmpeg packages; the current split only exists because we still have stragglers that couldn't be moved to v6.

@zlice
Copy link
Contributor

zlice commented Jan 6, 2025

i'll make a pr for the ffmpeg4 bit. don't think many people would have it installed. it's not even on my system.

edit: actually what's the best way to go about that...sounds like a few steps of metapkg/replace ?

  • make ffmpeg > ffmpeg4
  • make ffmpeg > meta for ffmpeg6 ?

next pr (this pr?)

  • make ffmpeg7
  • make ffmpeg > meta for ffmpeg7

edit-edit:

actually, do we even want to do this? ffmpeg8 will eventually come out, then it's the same song and dance again

@classabbyamp
Copy link
Member

let's go with ffmpeg as a metapackage

@ahesford
Copy link
Member

ahesford commented Jan 6, 2025

I was thinking ffmpeg and its subs would just be the actual package of whatever the current version is. That way, we avoid piling up old versions that will need manual cleaning.

@zlice
Copy link
Contributor

zlice commented Jan 6, 2025

then you can't update in waves like 6 did. everything will have to go at once

(luckily a lot of packages aren't using the system ffmpeg now, so it's not as painful. but still about 80-90 packages that need updated at a single time. 30 seemed to be the sweet-spot for ci to build and be happy w/o timeouts)

@ahesford
Copy link
Member

ahesford commented Jan 6, 2025

I think we should strive for a single ffmpeg version at any given time, then deal with spawning a new version only under extenuating circumstances. In this case, I think we should get everything currently building with ffmpeg6 building with v7 before accepting this package.

@zlice
Copy link
Contributor

zlice commented Jan 7, 2025

so qt5 and qt6 both say 'ffmpeg >= 5' is not supported (but i think really mean ffmpeg7, as 6 appears to be building webengine)

i'm sure they can be patched but other programs like chromium started using built-in ffmpeg. cuts out some codecs and new features from the system ffmpeg in kde browsers but would be less work for void members.

qt6-pdf(webengine)
configure.cmake:    MESSAGE "Unmodified ffmpeg >= 5.0 is not supported."

qt5-webengine
src/buildtools/configure.json:            "message": "Unmodified ffmpeg >= 5.0 is not supported. Please configure with -qt-webengine-ffmpeg."

@zlice zlice mentioned this pull request Jan 7, 2025
@zlice
Copy link
Contributor

zlice commented Feb 5, 2025

@mmdbalkhi mmdbalkhi requested review from classabbyamp and zlice June 5, 2025 23:04
@ahesford
Copy link
Member

ahesford commented Jun 5, 2025

I still have not seen a convincing argument for keeping this a separate package with a versioned name rather than moving the current ffmpeg to ffmpeg4 and allowing ffmpeg to move to version 7.

Versioned package names are a necessary evil in some cases. Creating more of them in advance because we might think that someday we will want to keep a legacy ffmpeg7 just complicates the package graph to achieve something we can easily do later when the need arises. Versioned package names lead to discontinuities in package history that eventually require manual intervention. Don't borrow trouble!

@zlice
Copy link
Contributor

zlice commented Jun 6, 2025

looks like abby is working on axing 4. was taking a look at my 'ffmpeg-meta' pr because it wasn't building for a bit (and i didnt care bc openmw and kodi are still not released) but nothing relying on 4 should make it even easier to just do 4 -> 7 and remove 6 or something. vlc should be the only ffmpeg4 straggler

@gAlleb
Copy link
Contributor

gAlleb commented Aug 25, 2025

And please add --enable-libsoxr (libsoxr-devel).

@github-actions
Copy link

Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.

@github-actions github-actions bot added the Stale label Nov 24, 2025
@github-actions github-actions bot closed this Dec 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

new-package This PR adds a new package Stale

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants