localsearch incorrectly requires ffmpeg

[Dmitrij]

My main question is: why does Nautilus require ffmpeg? Is this supposed to be the case, or is it a bug? As far as I understand, the problem lies with localsearch, but I have disabled everything unnecessary for it, and it still requires ffmpeg, which is strange. I don't remember ffmpeg being required for installing the basic Gnome system before.

Code: Select all

dima@mediaserver ~ $ emerge -pv --tree app-misc/localsearch

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!
Dependency resolution took 2.97 s (backtrack: 0/20).

[ebuild  N    ~] app-misc/localsearch-3.10.2:3::gentoo  USE="(seccomp) -cue -exif (-gif) -gsf -gstreamer -iptc -iso -jpeg -pdf -playlist -raw -test -tiff -upower -webp -xml -xmp -xps" 0 KiB
[ebuild  N     ]  media-video/ffmpeg-7.1.3:0/59.61.61::gentoo  USE="bzip2 dav1d drm fontconfig gnutls gpl jpegxl lcms libass opengl opus postproc pulseaudio sdl soc svg truetype vaapi vorbis vpx vulkan webp x264 xml xvid zlib -X -alsa (-amf) (-amr) -amrenc (-appkit) -bluray (-bs2b) -cdio -chromaprint -chromium -codec2 (-cuda) -doc (-dvd) -fdk -flite -frei0r -fribidi -gcrypt -gme -gmp -gsm -iec61883 (-ieee1394) -jack -jpeg2k -kvazaar -ladspa -lame -libaom -libaribb24 -libcaca -libilbc -liblc3 -libplacebo -librtmp -libsoxr -lv2 -lzma -modplug (-nvenc) -ocr -openal -opencl -openh264 -openmpt -openssl -qrcode (-qsv) (-quirc) -rabbitmq -rav1e -rubberband -samba -shaderc -snappy -sndio -speex -srt -ssh -svt-av1 -theora -twolame -v4l (-vdpau) -verify-sig -vidstab -x265 -zeromq -zimg (-zvbi)" 0 KiB
[ebuild  N     ]  app-misc/tinysparql-3.8.2:3/0::gentoo  USE="systemd -gtk-doc -localsearch -stemmer -test -vala -zeroconf" 0 KiB
[ebuild  N     ]   app-text/asciidoc-10.2.1::gentoo  USE="-test" PYTHON_SINGLE_TARGET="python3_13 (-pypy3_11) -python3_11 -python3_12 -python3_14" 0 KiB

Code: Select all

dima@mediaserver ~ $ cat /etc/portage/package.use/use-flags | grep localsearch
app-misc/tinysparql -localsearch
app-misc/localsearch -exif -gstreamer -iso -jpeg -pdf -playlist -tiff -upower -webp -xml

I think it can be usefull

Code: Select all

OS: Gentoo Linux aarch64
Host: Xunlong Orange Pi 5
Kernel: Linux 6.16.0-rc3-edge-rockchip64

Initially, I wanted to open an issue on GitHub Gentoo Portage, but unfortunately, you cannot create issues there, only merge requests.
It is also unclear why localsearch is required for installing nautilus, even though it appears to be disabled in tinysparql.

[Banana]

Well the ebuild files nautilus-48.4.1-r1.ebuild, localsearch-3.10.2.ebuild do specifiy them as RDEPEND. So technically everything is fine there.

Since I do not use gnome, what happend if you add -ffmpeg to your /etc/portage/package.use/use-flags file?

Abouit the why this is really needed, I don't know.

[Hu]

There is a comment in the nautilus ebuild:

Code: Select all

# Uses org.freedesktop.Tracker.Miner.Files gsettings schema from localsearch

I assume this is why nautilus is marked as having an RDEPEND on localsearch. This applies directly from nautilus, independent of what tinysparql requires.

localsearch appears to have an unconditional RDEPEND on ffmpeg, so I think the only way to avoid ffmpeg is to avoid localsearch. In turn, to avoid localsearch, you must avoid nautilus.

[flexibeast]

Upstream localsearch relies on ffmpeg (or libav) for metadata extraction: https://gitlab.gnome.org/GNOME/localsea ... quests/579

[sam_]

Initially, I wanted to open an issue on GitHub Gentoo Portage, but unfortunately, you cannot create issues there, only merge requests.
It is also unclear why localsearch is required for installing nautilus, even though it appears to be disabled in tinysparql.

Others have addressed the rest, but I'll answer this part: we use github only as a mirror to receive pull requests, but not bug reports. Also, Portage would not be the repository you want (Portage is the package manager), but the 'gentoo/gentoo' repository instead. But for something like this, a bug report is better once you're confident it is actually incorrect (which does not seem to be the case here).

Our bug reports are at bugs.gentoo.org.

[Dmitrij]

Thank you very much, I think I have managed to identify the cause of the difference. The thing is, my main machine has localsearch-3.8.2 installed, while arm64, since the package support is experimental, has localsearch-3.10.2 installed, and since version localsearch-3.9.0, a dependency on ffmpeg was added, and it cannot be changed with flags. The older version did not require ffmpeg, and as a result, I was able to compile nautilus without ffmpeg, but arm64 immediately chose the latest version of localsearch-3.10.2 for testing, which had a dependency on localsearch-3.10.2. Let's hope this is a temporary dependency that will be fixed in future versions, because it seems strange for a file manager to drag along a dependency on an audio conversion library.

[Hu]

As explained above, the file manager doesn't depend on an audio library. The file manager depends on localsearch because of a gsettings schema. In turn, localsearch depends on ffmpeg for audio processing. This could be fixed by splitting the gsettings schema out of localsearch, or by localsearch supporting a build mode where it lacks the ability to access audio metadata (and therefore doesn't need to depend on ffmpeg). Neither of those seem like things Gentoo would undertake on its own; if they are important, upstream should do them, and then Gentoo will inherit those improvements when upstream releases them.

Based on my experience with GNOME, I wouldn't expect this to get fixed. GNOME seems to be very big on dictating how people will use their projects, and prefers removing choices over adding them.