[gentoo-dev] [PATCH] ffmpeg-compat.eclass: new eclass

[gentoo-dev] [PATCH] ffmpeg-compat.eclass: new eclass

[Ionen Wolkens]

Sending this to dev ML in advance given it's simple and "probably"
won't need to change the code further.

If interested in the whole deal, see the PR instead:
https://github.com/gentoo/gentoo/pull/40942

--- (actual commit message below)

Both the slotting method and eclass are meant to be as simple
as possible, and isolated so that it does not really need to
work with everything given non-slotted ffmpeg stays.

Did not want turn ffmpeg into a permanent slotting model with
a FFMPEG_SLOT use_expand, eselect, or such potentially turning
it into a special Gentoo-only thing that often need hacks.

Essentially just a way for broken packages to gain time without
blocking everyone's ffmpeg updates.

Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
---
 eclass/ffmpeg-compat.eclass | 69 +++++++++++++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 eclass/ffmpeg-compat.eclass

diff --git a/eclass/ffmpeg-compat.eclass b/eclass/ffmpeg-compat.eclass
new file mode 100644
index 000000000000..2d675ab4cc66
--- /dev/null
+++ b/eclass/ffmpeg-compat.eclass
@@ -0,0 +1,69 @@
+# Copyright 2025 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: ffmpeg-compat.eclass
+# @MAINTAINER:
+# Ionen Wolkens <ionen@gentoo.org>
+# @AUTHOR:
+# Ionen Wolkens <ionen@gentoo.org>
+# @SUPPORTED_EAPIS: 8
+# @BLURB: Helper functions to link with slotted ffmpeg-compat libraries
+# @DESCRIPTION:
+# To use this, run ``ffmpeg_compat_setup <slot>`` before packages use
+# pkg-config, depend on media-video/ffmpeg-compat:<slot>=, and ensure
+# usage of both pkg-config --cflags and --libs (which adds -Wl,-rpath
+# to find libraries at runtime).
+#
+# This eclass is intended as a quick-to-setup alternative to setting
+# an upper bound on ffmpeg for packages broken with the latest version,
+# and thus allow users to upgrade their normal ffmpeg.
+#
+# This should still be a temporary measure, and it is recommended to
+# keep migration bugs open rather than consider this eclass as being
+# the "fix".
+#
+# Unlike LLVM_SLOT-style, this does not have USE to select the slot
+# and should instead pick only the highest one usable until package
+# is fixed and can use non-slotted ffmpeg again.
+#
+# Do *not* use both like ``|| ( <ffmpeg-<ver> ffmpeg-compat:<slot> )``,
+# the package manager cannot know which version it linked against
+# without USE flags.  Unfortunately means a period where users may
+# have two identical versions in stable before the newest major version
+# is stabilized, but idea is to not mangle normal ffmpeg with slotting
+# logic and make this an isolated temporary deal.
+
+case ${EAPI} in
+	8) ;;
+	*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
+
+if [[ -z ${_FFMPEG_COMPAT_ECLASS} ]]; then
+_FFMPEG_COMPAT_ECLASS=1
+
+# @FUNCTION: ffmpeg_compat_get_prefix
+# @USAGE: <slot>
+# @DESCRIPTION:
+# Return prefix of the installed ffmpeg-compat:<slot>.  Binaries like
+# ffmpeg will be found under <prefix>/bin if needed.
+ffmpeg_compat_get_prefix() {
+	(( ${#} == 1 )) || die "Usage: ${FUNCNAME} <slot>"
+
+	echo "${EPREFIX}/usr/lib/ffmpeg${1}"
+}
+
+# @FUNCTION: ffmpeg_compat_setup
+# @USAGE: <slot>
+# @DESCRIPTION:
+# Add ESYSROOT's ffmpeg-compat:<slot> to PKG_CONFIG_PATH for the
+# current ABI.  Can be called multiple times for multilib.
+ffmpeg_compat_setup() {
+	(( ${#} == 1 )) || die "Usage: ${FUNCNAME} <slot>"
+
+	local path=${SYSROOT}$(ffmpeg_compat_get_prefix "${1}")
+	[[ ${PKG_CONFIG_PATH} =~ (.*)"${path}"/[^/]+/pkgconfig:(.*) ]] &&
+		PKG_CONFIG_PATH=${BASH_REMATCH[1]}${BASH_REMATCH[2]}
+	export PKG_CONFIG_PATH=${path}/$(get_libdir)/pkgconfig:${PKG_CONFIG_PATH}
+}
+
+fi
-- 
2.48.1

Re: [gentoo-dev] [PATCH] ffmpeg-compat.eclass: new eclass

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 4505 bytes --]

On Sat, 2025-03-08 at 22:34 -0500, Ionen Wolkens wrote:
> Sending this to dev ML in advance given it's simple and "probably"
> won't need to change the code further.
> 
> If interested in the whole deal, see the PR instead:
> https://github.com/gentoo/gentoo/pull/40942
> 
> --- (actual commit message below)
> 
> Both the slotting method and eclass are meant to be as simple
> as possible, and isolated so that it does not really need to
> work with everything given non-slotted ffmpeg stays.
> 
> Did not want turn ffmpeg into a permanent slotting model with
> a FFMPEG_SLOT use_expand, eselect, or such potentially turning
> it into a special Gentoo-only thing that often need hacks.
> 
> Essentially just a way for broken packages to gain time without
> blocking everyone's ffmpeg updates.
> 
> Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
> ---
>  eclass/ffmpeg-compat.eclass | 69 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 69 insertions(+)
>  create mode 100644 eclass/ffmpeg-compat.eclass
> 
> diff --git a/eclass/ffmpeg-compat.eclass b/eclass/ffmpeg-compat.eclass
> new file mode 100644
> index 000000000000..2d675ab4cc66
> --- /dev/null
> +++ b/eclass/ffmpeg-compat.eclass
> @@ -0,0 +1,69 @@
> +# Copyright 2025 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# @ECLASS: ffmpeg-compat.eclass
> +# @MAINTAINER:
> +# Ionen Wolkens <ionen@gentoo.org>
> +# @AUTHOR:
> +# Ionen Wolkens <ionen@gentoo.org>
> +# @SUPPORTED_EAPIS: 8
> +# @BLURB: Helper functions to link with slotted ffmpeg-compat libraries
> +# @DESCRIPTION:
> +# To use this, run ``ffmpeg_compat_setup <slot>`` before packages use
> +# pkg-config, depend on media-video/ffmpeg-compat:<slot>=, and ensure
> +# usage of both pkg-config --cflags and --libs (which adds -Wl,-rpath
> +# to find libraries at runtime).
> +#
> +# This eclass is intended as a quick-to-setup alternative to setting
> +# an upper bound on ffmpeg for packages broken with the latest version,
> +# and thus allow users to upgrade their normal ffmpeg.
> +#
> +# This should still be a temporary measure, and it is recommended to
> +# keep migration bugs open rather than consider this eclass as being
> +# the "fix".
> +#
> +# Unlike LLVM_SLOT-style, this does not have USE to select the slot
> +# and should instead pick only the highest one usable until package
> +# is fixed and can use non-slotted ffmpeg again.
> +#
> +# Do *not* use both like ``|| ( <ffmpeg-<ver> ffmpeg-compat:<slot> )``,
> +# the package manager cannot know which version it linked against
> +# without USE flags.  Unfortunately means a period where users may
> +# have two identical versions in stable before the newest major version
> +# is stabilized, but idea is to not mangle normal ffmpeg with slotting
> +# logic and make this an isolated temporary deal.
> +
> +case ${EAPI} in
> +	8) ;;
> +	*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
> +esac
> +
> +if [[ -z ${_FFMPEG_COMPAT_ECLASS} ]]; then
> +_FFMPEG_COMPAT_ECLASS=1
> +
> +# @FUNCTION: ffmpeg_compat_get_prefix
> +# @USAGE: <slot>
> +# @DESCRIPTION:
> +# Return prefix of the installed ffmpeg-compat:<slot>.  Binaries like
> +# ffmpeg will be found under <prefix>/bin if needed.
> +ffmpeg_compat_get_prefix() {
> +	(( ${#} == 1 )) || die "Usage: ${FUNCNAME} <slot>"
> +
> +	echo "${EPREFIX}/usr/lib/ffmpeg${1}"
> +}
> +
> +# @FUNCTION: ffmpeg_compat_setup
> +# @USAGE: <slot>
> +# @DESCRIPTION:
> +# Add ESYSROOT's ffmpeg-compat:<slot> to PKG_CONFIG_PATH for the
> +# current ABI.  Can be called multiple times for multilib.
> +ffmpeg_compat_setup() {
> +	(( ${#} == 1 )) || die "Usage: ${FUNCNAME} <slot>"
> +
> +	local path=${SYSROOT}$(ffmpeg_compat_get_prefix "${1}")
> +	[[ ${PKG_CONFIG_PATH} =~ (.*)"${path}"/[^/]+/pkgconfig:(.*) ]] &&
> +		PKG_CONFIG_PATH=${BASH_REMATCH[1]}${BASH_REMATCH[2]}
> +	export PKG_CONFIG_PATH=${path}/$(get_libdir)/pkgconfig:${PKG_CONFIG_PATH}
> +}
> +
> +fi

I like this approach. We've generally been quite good at dragging upstreams to
the latest, so it would be a shame to go fully slotted.

The regex check seems like overkill to me, but perhaps I've missed something.

This currently won't work when cross-compiling as cross-pkg-config currently
unsets PKG_CONFIG_PATH, but I have been thinking about changing that. That was
done to tame non-Gentoo environments, but no one else uses crossdev in
reality.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 858 bytes --]

Re: [gentoo-dev] [PATCH] ffmpeg-compat.eclass: new eclass

[Ionen Wolkens]

[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]

On Sun, Mar 09, 2025 at 10:17:42AM +0000, James Le Cuirot wrote:
> > +ffmpeg_compat_setup() {
> > +	(( ${#} == 1 )) || die "Usage: ${FUNCNAME} <slot>"
> > +
> > +	local path=${SYSROOT}$(ffmpeg_compat_get_prefix "${1}")
> > +	[[ ${PKG_CONFIG_PATH} =~ (.*)"${path}"/[^/]+/pkgconfig:(.*) ]] &&
> > +		PKG_CONFIG_PATH=${BASH_REMATCH[1]}${BASH_REMATCH[2]}
> > +	export PKG_CONFIG_PATH=${path}/$(get_libdir)/pkgconfig:${PKG_CONFIG_PATH}
> > +}
> > +
> > +fi
> 
> I like this approach. We've generally been quite good at dragging upstreams to
> the latest, so it would be a shame to go fully slotted.
> 
> The regex check seems like overkill to me, but perhaps I've missed something.

Well, guess could let the multilib paths accumulate given it'll try
the first one anyway. It was just cleaning up the previous one that it
shouldn't use.

> 
> This currently won't work when cross-compiling as cross-pkg-config currently
> unsets PKG_CONFIG_PATH, but I have been thinking about changing that. That was
> done to tame non-Gentoo environments, but no one else uses crossdev in
> reality.

Really? There's a few others eclasses that set PKG_CONFIG_PATH.. does
nothing work?
-- 
ionen

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] [PATCH] ffmpeg-compat.eclass: new eclass

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

On Sun, 2025-03-09 at 06:27 -0400, Ionen Wolkens wrote:
> On Sun, Mar 09, 2025 at 10:17:42AM +0000, James Le Cuirot wrote:
> > > +ffmpeg_compat_setup() {
> > > +	(( ${#} == 1 )) || die "Usage: ${FUNCNAME} <slot>"
> > > +
> > > +	local path=${SYSROOT}$(ffmpeg_compat_get_prefix "${1}")
> > > +	[[ ${PKG_CONFIG_PATH} =~ (.*)"${path}"/[^/]+/pkgconfig:(.*) ]] &&
> > > +		PKG_CONFIG_PATH=${BASH_REMATCH[1]}${BASH_REMATCH[2]}
> > > +	export PKG_CONFIG_PATH=${path}/$(get_libdir)/pkgconfig:${PKG_CONFIG_PATH}
> > > +}
> > > +
> > > +fi
> > 
> > I like this approach. We've generally been quite good at dragging upstreams to
> > the latest, so it would be a shame to go fully slotted.
> > 
> > The regex check seems like overkill to me, but perhaps I've missed something.
> 
> Well, guess could let the multilib paths accumulate given it'll try
> the first one anyway. It was just cleaning up the previous one that it
> shouldn't use.
> 

That's what I thought. I don't mind too much.

> > This currently won't work when cross-compiling as cross-pkg-config currently
> > unsets PKG_CONFIG_PATH, but I have been thinking about changing that. That was
> > done to tame non-Gentoo environments, but no one else uses crossdev in
> > reality.
> 
> Really? There's a few others eclasses that set PKG_CONFIG_PATH.. does
> nothing work?

Seems like things I haven't generally tried to cross-compile.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 858 bytes --]

Re: [gentoo-dev] [PATCH] ffmpeg-compat.eclass: new eclass

[Ionen Wolkens]

[-- Attachment #1: Type: text/plain, Size: 2286 bytes --]

On Sun, Mar 09, 2025 at 10:33:13AM +0000, James Le Cuirot wrote:
> On Sun, 2025-03-09 at 06:27 -0400, Ionen Wolkens wrote:
> > On Sun, Mar 09, 2025 at 10:17:42AM +0000, James Le Cuirot wrote:
> > > > +ffmpeg_compat_setup() {
> > > > +	(( ${#} == 1 )) || die "Usage: ${FUNCNAME} <slot>"
> > > > +
> > > > +	local path=${SYSROOT}$(ffmpeg_compat_get_prefix "${1}")
> > > > +	[[ ${PKG_CONFIG_PATH} =~ (.*)"${path}"/[^/]+/pkgconfig:(.*) ]] &&
> > > > +		PKG_CONFIG_PATH=${BASH_REMATCH[1]}${BASH_REMATCH[2]}
> > > > +	export PKG_CONFIG_PATH=${path}/$(get_libdir)/pkgconfig:${PKG_CONFIG_PATH}
> > > > +}
> > > > +
> > > > +fi
> > > 
> > > I like this approach. We've generally been quite good at dragging upstreams to
> > > the latest, so it would be a shame to go fully slotted.
> > > 
> > > The regex check seems like overkill to me, but perhaps I've missed something.
> > 
> > Well, guess could let the multilib paths accumulate given it'll try
> > the first one anyway. It was just cleaning up the previous one that it
> > shouldn't use.
> > 
> 
> That's what I thought. I don't mind too much.

I went ahead and removed it, on 2nd thought I didn't like it either.
Thanks.

> > > This currently won't work when cross-compiling as cross-pkg-config currently
> > > unsets PKG_CONFIG_PATH, but I have been thinking about changing that. That was
> > > done to tame non-Gentoo environments, but no one else uses crossdev in
> > > reality.
> > 
> > Really? There's a few others eclasses that set PKG_CONFIG_PATH.. does
> > nothing work?
> 
> Seems like things I haven't generally tried to cross-compile.

It's used for the same purpose in e.g. lua eclasses which put their
lua.pc in ${T}. Not looked too closely but python, vala, postgres
eclasses to do this too. It's likely that cross still "works" given
it uses the system's .pc file which could be the wrong version.

Much like how it'll still "work" here by linking to the unslotted
ffmpeg.. albeit these packages will likely be broken with latest
version and fail to build :) Been seeing it as the failsafe.

I do think this should be changed as well anyhow, maybe it could
only filter paths not in ROOT.. or so I'd like to say, but that
doesn't handle the T or WORKDIR cases.
-- 
ionen

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] [PATCH] ffmpeg-compat.eclass: new eclass

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1439 bytes --]

On 3/8/25 10:34 PM, Ionen Wolkens wrote:
> Sending this to dev ML in advance given it's simple and "probably"
> won't need to change the code further.
> 
> If interested in the whole deal, see the PR instead:
> https://github.com/gentoo/gentoo/pull/40942
> 
> --- (actual commit message below)
> 
> Both the slotting method and eclass are meant to be as simple
> as possible, and isolated so that it does not really need to
> work with everything given non-slotted ffmpeg stays.
> 
> Did not want turn ffmpeg into a permanent slotting model with
> a FFMPEG_SLOT use_expand, eselect, or such potentially turning
> it into a special Gentoo-only thing that often need hacks.
> 
> Essentially just a way for broken packages to gain time without
> blocking everyone's ffmpeg updates.


What's the advantage of this over, say, just having ffmpeg itself with
slotting, but only supporting the tools with the latest slot and having
all old versions be library-only?


If you anyways have to modify packages relying on older versions as soon
as a newer version goes stable, then it seems like there shouldn't be a
major difference here. And keeping it all in one PN would mean you don't
have issues with ffmpeg and ffmpeg-compat wanting to install each
others' libraries and maybe ending up with both installed. You also
wouldn't need to e.g. maintain the same patchset for multiple packages.


-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-dev] [PATCH] ffmpeg-compat.eclass: new eclass

[Ionen Wolkens]

[-- Attachment #1: Type: text/plain, Size: 3610 bytes --]

On Sun, Mar 09, 2025 at 12:45:37PM -0400, Eli Schwartz wrote:
> On 3/8/25 10:34 PM, Ionen Wolkens wrote:
> > Sending this to dev ML in advance given it's simple and "probably"
> > won't need to change the code further.
> > 
> > If interested in the whole deal, see the PR instead:
> > https://github.com/gentoo/gentoo/pull/40942
> > 
> > --- (actual commit message below)
> > 
> > Both the slotting method and eclass are meant to be as simple
> > as possible, and isolated so that it does not really need to
> > work with everything given non-slotted ffmpeg stays.
> > 
> > Did not want turn ffmpeg into a permanent slotting model with
> > a FFMPEG_SLOT use_expand, eselect, or such potentially turning
> > it into a special Gentoo-only thing that often need hacks.
> > 
> > Essentially just a way for broken packages to gain time without
> > blocking everyone's ffmpeg updates.
> 
> 
> What's the advantage of this over, say, just having ffmpeg itself with
> slotting, but only supporting the tools with the latest slot and having
> all old versions be library-only?
> If you anyways have to modify packages relying on older versions as soon
> as a newer version goes stable, then it seems like there shouldn't be a
> major difference here. And keeping it all in one PN would mean you don't
> have issues with ffmpeg and ffmpeg-compat wanting to install each
> others' libraries and maybe ending up with both installed. You also
> wouldn't need to e.g. maintain the same patchset for multiple packages.

Having packages that behave differently within the same namespace
sound confusing to me (and likely to users too). Not only will they have
no tools, but have headers and pkg-config files in non-standard
locations (if not renamed, but that's not better). It's essentially a
slot that's only for other ebuilds, not users.

Don't like the idea of juggling which version provides what too.
Like stable ffmpeg-6.1.2 w/ tools, ~arch ffmpeg-6.1.2-r1 w/o tools
plus ~arch ffmpeg-7.1.1 w/ tools. Kind of confusing and not clear-cut.
Plus we may want to keep several branches and versions, maybe a user
actually wants ffmpeg-6's tools due to some niche regression until
it's fixed. Having all this under media-video/ffmpeg feels messy.

wrt same time, if we *really* don't want that, could always have them
either block each others until versions get cleaned up, it ends up
being the same save for the patches bit.

...but it feels like an unnecessary restriction to me, even if we sync
up all stabilizations perfectly, users will do still accept_keywords
and such (esp. ~arch-only packages) and then run into blockers without
necessarily wanting the latest ffmpeg too.

Also, I'm hoping for usage of ffmpeg-compat to be really low. It's
meant to be a isolated last resort, new ffmpeg major versions will
still be added masked, then we'll try to fix most packages esp.
popular ones, and then give ffmpeg-compat to the rest and hopefully
not get it on many users' system. Problem is that (right now) it's
staying masked for way too long.

wrt patches, current ffmpeg-compat is sharing patches through a tarball
right now, good excuse to kill the 128kB files/ -- not that we couldn't
duplicate a few patches on short notice (but I agree it's not ideal).
The ebuilds are also identical, ffmpeg-compat is not meant to be
maintained on its own until the non-compat equivalent is removed,
just copy incl. keywords. The ${PN} change currently acts as the
trigger to become slotted (not that changing a variable instead would
be a big deal).
-- 
ionen

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] [PATCH] ffmpeg-compat.eclass: new eclass

[Ionen Wolkens]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

On Sat, Mar 08, 2025 at 10:34:31PM -0500, Ionen Wolkens wrote:
> Sending this to dev ML in advance given it's simple and "probably"
> won't need to change the code further.
> 
> If interested in the whole deal, see the PR instead:
> https://github.com/gentoo/gentoo/pull/40942
On a side-note, the ffmpeg ebuild was also rewritten in that PR which
may be of more interest than the slotting to some.

See the `rewrite live ebuild` commit message if want details, some
changes are debatable and may anger some users, albeit I'm mostly
aiming for stabler ffmpeg.
-- 
ionen

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[gentoo-dev] Re: [PATCH] ffmpeg-compat.eclass: new eclass

[Duncan]

Ionen Wolkens posted on Sun, 9 Mar 2025 15:34:51 -0400 as excerpted:

> On Sat, Mar 08, 2025 at 10:34:31PM -0500, Ionen Wolkens wrote:
>> Sending this to dev ML in advance given it's simple and "probably"
>> won't need to change the code further.

So the will-be-slot tracker bugs may in the (long) bug list at the bottom 
of the PR, but I didn't see them specifically named either here or in the 
PR.  In the interest of preventing duplicated effort here's what I found

https://bugs.gentoo.org/831437  ffmpeg-5 (4 compat)

One remaining open bug.  media-sound/moc.  Latest in-tree is a 2016 
alpha.  There are active users and newer overlay versions with ffmpeg-6 
compat at least.  Alternatives are killing USE=ffmpeg or last-riting.

Bottom line:  As the PM says a 4-compat slot is likely to be short-lived.

https://bugs.gentoo.org/901257  ffmpeg-6.0 (5 compat)

Again just one open bug, and shorter list in general.  But that bug is 
media-libs/gegl (gimp dep).  Test not build failure and upstream 
apparently says no big deal.  Again killing USE=ffmpeg is one (bad?) 
alternative.  From the bug it's almost good with ffmpeg-7 (one remaining 
test failure.)

Bottom line:  An ffmpeg-6 compat slot /could/ be short-lived as well, and 
if not, certainly the slot should indeed be very limited usage (gegl only 
unless something else pops up).

https://bugs.gentoo.org/928905  ffmpeg-7.0 (6 compat, deps on the above 
two also)

As might be expected ffmpeg-7 still has a decent number of open bugs, tho 
a scan suggests ~2/3 are fixed already.  The 6-compat slot would thus get 
more usage including (as of my last sync) both xine-lib and mplayer latest 
(non-live) in-tree, so many users will likely need it.

>> If interested in the whole deal, see the PR instead:
>> https://github.com/gentoo/gentoo/pull/40942
> On a side-note, the ffmpeg ebuild was also rewritten in that PR which
> may be of more interest than the slotting to some.

> See the `rewrite live ebuild` commit message if want details, some
> changes are debatable and may anger some users, albeit I'm mostly aiming
> for stabler ffmpeg.

Having looked over that live ebuild commit message, LGTM; yes a bunch of 
changes but no "anger some users" here! =:^)

(FWIW I'm on ffmpeg-live (due to firefox/youtube stalls on the last 
release I checked that are fixed in live) and seem to have 1/2-2/3 the USE 
flag changes set already.  I'll likely set the others on next update (as 
you surely already know the ffmpeg-live commit-stream's a firehose so it's 
a virtually guaranteed smart-live-rebuild), whether the rewrite's in-tree 
or not by then.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [PATCH] ffmpeg-compat.eclass: new eclass

[Ionen Wolkens]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

On Tue, Mar 11, 2025 at 04:37:50AM -0000, Duncan wrote:
> Ionen Wolkens posted on Sun, 9 Mar 2025 15:34:51 -0400 as excerpted:
> 
> > On Sat, Mar 08, 2025 at 10:34:31PM -0500, Ionen Wolkens wrote:
> >> Sending this to dev ML in advance given it's simple and "probably"
> >> won't need to change the code further.
> 
> So the will-be-slot tracker bugs may in the (long) bug list at the bottom 
> of the PR, but I didn't see them specifically named either here or in the 
> PR.  In the interest of preventing duplicated effort here's what I found

Yes, migration & tracker bugs haven't been handled yet, that's for
a follow up (after merge). The only exception is moc which is used
as an example.

Right now this is mostly fixing bugs of ffmpeg itself, not the bugs
of revdeps, all while preparing things to start checking these.

> Bottom line:  As the PM says a 4-compat slot is likely to be short-lived.

Indeed, albeit still need to recheck some of the in-tree packages
(likewise for other ffmpeg versions), tracker bugs can be missing
things esp. if some devs added upper bounds without filing a bug.
For ffmpeg-7, some may still need to be discovered -- tinderboxes
unmasking it sometimes don't catch everything.

Can probably kill 4 anytime anyhow, but no hurry, ffmpeg-4 isn't too
broken yet.

> > See the `rewrite live ebuild` commit message if want details, some
> > changes are debatable and may anger some users, albeit I'm mostly aiming
> > for stabler ffmpeg.
> 
> Having looked over that live ebuild commit message, LGTM; yes a bunch of 
> changes but no "anger some users" here! =:^)

Cool :)
-- 
ionen

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]