Two versions to support the range of (not-masked) in-tree
nvidia-drivers and what older ffmpeg versions may require to work
(albeit unneededed right now, ffmpeg-6.1.1 is broken with 13.0
but that version is due for cleanup either way).
Add a pkg_postinst to inform of driver support, but do not reintroduce
a nvidia-drivers RDEPEND (leads to complications and this is supposed
to be headers-only, runtime is optional).
Also simplify the ebuild, the makefile's `all` target does nothing
but a sed (not worth a src_compile), and the unintuitive LIBDIR=share
installs to /usr/<libdir>/pkgconfig like the `mv` does.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
May as well take too, same pseudo-upstream as ffmpeg and it can
be sensitive to the versions sometimes requiring to set upper or
lower bounds.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Others are still welcome to work on this though, it's just that
media-video is mostly a placeholder project at this point and
hasn't touched ffmpeg in nearly 3 years.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
With USE="-doc test", if we have dev-ada/e3-testsuite installed but not
dev-python/sphinx, we end up failing because we don't return early if
*ONLY* USE=test and end up looking for doc deps.
Feel like I'm missing a more elegant way of doing this (other than relying
on just the implicit return which doesnt't simplify much) but let's get
it fixed in any case.
Bug: https://bugs.gentoo.org/951067
Signed-off-by: Sam James <sam@gentoo.org>
As explained in the previous commit, pystring changed soname and thus we
had to introduce a subslot, and all revdeps need to depend on said
subslot. Also force a rebuild by revbumping.
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
```
* CMP: =dev-cpp/pystring-1.1.3-r1 with dev-cpp/pystring-1.1.4/image
* FILES:-usr/lib64/libpystring.so.0.0
* FILES:+usr/lib64/libpystring.so (-rwxr-xr-x root:root)
* SONAME:-libpystring.so.0.0(64)
* SONAME:+libpystring.so(64)
```
This breaks binpackage usage. preserved-libs sort of saves you, maybe,
if you built locally. Reverse dependencies are linked to .so.0.0, but
the new package only contains .so -- technically, if the reverse were
true, linked binaries would still work if you squint, but in the current
state this simply does not work at all.
The background here is weird. Upstream has a Makefile, which calls the
system libtool (broken!) and produces a soname of .so.0 in the event
that it succeeds at producing a library. We patched in an unofficial
cmake build (???) that set the soname to .so.0.0 instead, which isn't
very libtool of them but whatever. Upstream didn't actually accept that,
they wrote their own which is "simpler" and set the soname to .so.
Now we have 3 different sonames in use, but one of them was only in use
in *Gentoo* for a couple of days, unstable, back in 2021.
As standard, we solve changing sonames by bumping subslot to force a
rebuild. Straight to stable it goes, with a revbump since people
already have it installed and now have broken binaries.
Bug: https://github.com/gentoo/gentoo/pull/21209
Bug: https://github.com/gentoo/gentoo/pull/39761
Bug: https://github.com/imageworks/pystring/pull/29
Fixes: 91773fd1eb
Fixes: 4b6bedcedf
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
Ionen Wolkens
Joel Anderson
Michał Górny
Valérian Rousset
idealseal
Sam James
Joe Kappus
Alfred Wingate
Petr Vaněk
Eli Schwartz
Matthew C
NRK