+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.
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?
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
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.
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.
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.
Sending this to dev ML in advance given it's simple and "probably"On a side-note, the ffmpeg ebuild was also rewritten in that PR which
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 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:On a side-note, the ffmpeg ebuild was also rewritten in that PR which
https://github.com/gentoo/gentoo/pull/40942
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 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
Bottom line: As the PM says a 4-compat slot is likely to be short-lived.
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! =:^)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 475 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 17:50:36 |
| Calls: | 9,487 |
| Calls today: | 6 |
| Files: | 13,617 |
| Messages: | 6,121,090 |