omakade: declare qt6-svg, qt6-imageformats and hicolor-icon-theme

[tsouth89]

Omakade's upstream PKGBUILD added these runtime deps in 1.3.0 and the OPR copy is missing them. The app icon is an SVG rendered through QML (qt6-svg), WebP covers from Lutris, Faugus and RetroArch need qt6-imageformats, and the icon installs under hicolor.

Omarchy already pulls most of these in through the base install, so nothing is broken today. This just keeps the depends honest for anyone installing on plain Arch.

No version bump, the upstream sync handles that.

[omarchybot]

Reviewed. All three dependencies are correct and I verified each against the 1.2.3 source. One problem: as opened, this PR would not have reached a single user. I pushed the one-line fix — ba6ffb5.

The pkgrel. check_needs_build() builds ${pkgver}-${pkgrel} (build/build.sh:395) and compares it with the version already in the repository database (get_local_version(), build/build.sh:120), returning "already up to date" when they match (build/build.sh:415). At 1.2.3-1 that gate is closed, so the package never enters the build queue — scoped or unscoped. And even if it were rebuilt and republished by hand, pacman does not offer an equal 1.2.3-1 to anyone who already has it. The repo's own README says it plainly at line 383: "A rebuild that reuses the published version string produces a package pacman will never offer anyone."

"No version bump, the upstream sync handles that" does not hold, and it is worth showing where it stops rather than just asserting it. helpers/upstream-github.sh:124 returns {} when the checked-in pkgver equals upstream's, bin/sync-upstream:437 independently skips an equal version, and bin/sync-upstream:311 only resets pkgrel to 1 while applying a newer upstream version. Nothing in that path creates a packaging-only revision. The next sync to 1.2.4 will reset pkgrel to 1 and carry your depends forward, so the bump costs nothing then and is what makes the fix land now.

The three dependencies, verified against the v1.2.3 tarball (which hashes to dcbb57ca…, matching the PKGBUILD):

• qt6-imageformats — .webp is handled in four places: src/sources/lutris/LutrisScanner.cpp:22, src/sources/faugus/FaugusScanner.cpp:26, src/sources/retroarch/RetroArchScanner.cpp:91, and src/library/UnifiedGameModel.cpp:257 via QImageReader, with the file dialog offering *.webp at qml/Main.qml:327. Qt's WebP plugin lives in that package. Exactly as you described.
• qt6-svg — resources/icons/io.github.tsouth89.Omakade.svg, referenced from qml/Main.qml and src/app/main.cpp. Rendering it through QML needs the Qt SVG image-format plugin.
• hicolor-icon-theme — CMakeLists.txt:139 installs into ${CMAKE_INSTALL_DATADIR}/icons/hicolor/scalable/apps, which is the Arch convention for declaring it.

All three are depends rather than optdepends, correctly: they are needed for intended behaviour, not for an optional integration.

Nothing else is missing, which was the thing more worth checking than the three that were added. CMakeLists.txt:15 requests Concurrent Core Gui Network Qml Quick QuickControls2 Sql Test — all covered by qt6-base and qt6-declarative — and the complete set of QML imports across the tree is QtQuick, QtQuick.Controls, QtQuick.Dialogs, QtQuick.Layouts and QtQuick.Window, all in qt6-declarative. No Qt5Compat, no QtQuick.Effects, no multimedia or shadertools, so none of qt6-5compat, qt6-shadertools, qt6-multimedia, qt6-quick3d or qt6-webengine is implied. The declared set now looks complete.

Pushed: ba6ffb5 — pkgrel=2, nothing else.

Second opinion: codex at xhigh reviewed this independently and reached the same conclusion on the pkgrel, tracing the sync-upstream path to helpers/upstream-github.sh:124 and bin/sync-upstream:311/437 — that tracing is its contribution; I had only checked the build gate. It could not fetch the source tarball from its environment, so the dependency verification above is mine alone, from the actual 1.2.3 tree on a worker. Where we agree, its independence is not currently guaranteed.

Waiting on the maintainer.