| Git Clone URL: | https://aur.archlinux.org/highscore-git.git (read-only, click to copy) |
|---|---|
| Package Base: | highscore-git |
| Description: | A rewrite of Highscore, formerly gnome-games |
| Upstream URL: | https://gitlab.gnome.org/World/highscore |
| Licenses: | GPL-3.0-or-later |
| Conflicts: | highscore |
| Provides: | highscore |
| Submitter: | igor-dyatlov |
| Maintainer: | yochananmarqos |
| Last Packager: | yochananmarqos |
| Votes: | 29 |
| Popularity: | 0.68 |
| First Submitted: | 2021-08-07 14:40 (UTC) |
| Last Updated: | 2024-04-06 20:59 (UTC) |
@rien333: I appreciate the feedback. However, reverting that commit is not a viable solution. Newer commits have and will be based on newer commits from both libmanette and libadwaita.
Using VCS packages as dependencies will also not work all of the time since Flatpaks can use specific commits.
Building this currently shows 3 errors: two related to Gnome's libmanette (a game controller library), and one to a button row button in a preferences dialogue.
The first two are caused by libmanette's current stable release missing commits recently introduced into its main branch. This can be fixed by creating a libmanette-git package (though I do not think you should be maintaining even more packages, and just wait until upstream releases a new version)
The final error relates to upstream using an adwaita widget that is not in libadwaita 1.5 (which is what Arch currently ships). Fortunately, this is a matter of reverting a single commit:
prepare() {
cd "${pkgname%-git}"
# Revert: preferences-firmware-page: Use button row
git revert --no-commit e841485d9ff3147e7cf879c95d7ab55b94a7f399
}
The commit in question just changes the type of some button from a regular one to a new shiny one, so I presume reverting it introduces no breakages (long live tiny changes!)
@rien333: That sounds logical, so maybe libhighscore-<core-name>-git or something? However, for example the BlastEm core is already called blastem-highscore, hence my naming tactic. Either way, upstream is a WIP, so the developer might even add them as subprojects for all I know. We'll see.
@yochananmarqos: Good! Thank you for being so quick.
I do think that, in the package name, the string (lib)highscore- should come before mgba, though, rather than the ordering that is used now. This is more in line with the naming conventions established by libretro-*.
@rien333: I added most of the cores. ;)
This is what I have now, in terms of a libhighscore-libmgba PKGBUILD. Doesn't work with the actual highscore app yet, but it should be pretty close, given what I could decipher from the source code.
https://gist.github.com/rien333/11482029744fc74d03ab48b43213b4b4
PSA: This is a WIP. The developer only supports Flatpak, please do not create upstream issues.
Hm, just found this message on matrix. It seems that libretro is not supported anymore, and that cores have to ported to a new format (?):
so it's post-rewrite? it's not using libretro [in that case].
I have no intention of supporting non-flatpak builds, and especially not when the app is not even released and none of the components are stable in any way
In any case, the master branch of this application is completely dysfunctional at the moment. I will try to find out a good way of packaging, by inspecting the flatpacks files!
EDIT:
Okay, seems the lead developer is maintaining "libhighscore" builds of emulation cores in separate repos. For example:
https://github.com/alice-mkh/mgba
Which gets picked up in the build process through this file.
Thanks for the quick update!
I was wondering, does it indeed make sense to package libhighscore seperately? In Arch (as you know), libs are generally not separated into additional packages, unless they really makes sense as a standalone thing. And I would say that, in this case, the library barely has a standalone use-case. Like, what applications other than highscore are going to use this library? Its description also doesn't mention much in terms of it being broadly useful:
A shared library for Highscore cores
Of course, there is something to be said for the easiest solution, if that is the reasoning.
@rien333: The About dialog reports it's 0.1.0, so I'm going to wait until there's a tag instead of assuming. Either way, the current pkgver is "older" than the old tag, but I'd rather not use an epoch just to placate an AUR helper.
Pinned Comments
yochananmarqos commented on 2024-04-06 21:00 (UTC)
PSA: This is a WIP. The developer only supports Flatpak, please do not create upstream issues.