Add retroarch and libretro to Gentoo #122
Comments
|
You can find my work in progress at gentoo/gentoo#9330 |
Not sure what has happened to stefan Are there still plans to integrate these ebuilds into the tree? I do see several libretro ebuilds listed now, however they're tied to the Kodi media application, instead of RetroArch itself |
|
Is there any updates on this progress? not sure if I should still be submitting RetroArch version bumps here. |
|
I use libretro through Kodi, so that's what I've been working on. I'd like to not have libretro.eclass. Would you be interested in submitting a PR to https://github.com/gentoo/gentoo/ adding these packages, not using libretro.eclass? It doesn't look like that would be too much effort, the packages in this repo are a great start. We just need things to be simpler (ie, not using libretro.eclass, can games-emulation/retroarch's build/install be simpler than what the ebuild here does). I'd happily review and merge them if you did. I'd really like to get all of RetroArch into Gentoo. :) |
|
@jason-oliveira @candrews I'm very much new to writing and maintaining ebuilds, but I'd love to help spearhead some effort with getting Retroarch directly included in Gentoo. Work is progressing in the upstream project with ARM64 architecture support, which would be nice to include |
|
The best thing to do would be to make a PR to https://github.com/gentoo/gentoo/ I'll review, test, and provide help. If you do that, we can get this into Gentoo quite soon. |
|
@IntelMiner all patches welcome. @candrews when I can find time, I'll happily submit a PR. if IntelMiner doesn't do it first. The ebuild could definitely do with a rewrite. |
|
@jason-oliveira I've been using the ebuilds myself locally without too many issues. @stefan-gr did helpfully include an updater script which seems to rebase them against the git trunk builds of each repository If you want to rewrite them first and submit a PR, that'd be fine. If not, they look like they could likely be submitted as they are(?) |
|
I don't think libretro.eclass is going to be acceptable. I advise that the existing ebuilds be refactored to not use libretro.eclass then submitted to Gentoo. Note that I think we're only talking about these packages:
Many of the libretro emulators are in Gentoo already as |
|
This is being worked on. |
|
@jason-oliveira Are you aiming to get all the libretro cores included in a similar manner to the existing ebuilds? @candrews A lot of those ebuilds look rather out of date. As I understand it, RetroArch and its "Libretro" cores try to stay in sync with one another. Which may make tracking them a little difficult |
I'm happy to update them - are there any specifically that you'd like to see bumped? Also, the fact they the cores don't release versions makes tracking incredibly difficult. If you can convince them to release actual versions, that would make life much easier. |
|
@IntelMiner everything is currently living in https://gitlab.com/jason.oliveira/retroarch. All but the main ebuild are ported and working. Additions I made to the ebuild (updated dependencies, requests from RA devs) seem to have messed up the src_configure() step, so I'm walking-back the changes and re-iterating all my additions back in. So yeah, don't use the other repo for the next 48 hours or so, and then I'll be happy to start submitting them to gentoo via pull request (can gitlab and github interact? guess I'll find out!). @candrews Is there any objections to making most of the assets/shaders/cores live in userspace, say in ~/.local/retroarch/ subdirs? This is how Lutris and Steam operate, so I set this as the default configuration in the ebuilds I plan to submit. |
If they're executables, then that would not be acceptable. Everything must be built from source. If it's unclear, then I suggest you submit the PR to Gentoo, and we can take a look and figure it out - it'll be easier to have that conversation with a concrete ebuild than with an abstract proposal. |
|
Ugh. @stefan-gr, it profoundly saddens me that our mutual efforts on RetroArch and LibRetro have largely died and been left to bitrot across a medley of unstable and largely unmaintained overlays (e.g., vortex, menelkir). It's equally disappointing that most prior efforts to merge our work into the Portage tree (e.g., this ridiculous 10,000 commit patchset adding RetroArch, which was unsurprisingly closed without comment several years ago) also fell by the wayside and were summarily buried, excluding a few unstable and outdated LibRetro cores which mysteriously appeared in the Portage tree (e.g., This isn't anyone's fault, of course – or, rather, this was everyone's fault including my own. In the time-honoured spirit of "If you want something done, just put down that plastic-cracked SNES controller down and do it!", I'm strongly considering resurrecting quasi-official RetroArch support at raiagent, yet another overlay where I recently shepherded PySide2 into the Portage tree. The endgame would be exactly the same: preserve Portage-quality RetroArch support at raiagent until one or more official Gentoo developers relieve me of my terrible, exhausting, and debilitating burden by fully merging that support into the Portage tree. Because the current state of RetroArch on Gentoo is abysmally tragicomic,...except nobody's laughing, are they? this will probably happen. It's more a question of when, really. I'm currently hip-deep in a bold new open-source Python project into the uncharted recesses of the human soul, which consumes my precious volunteer resources. Once I excrete out the next stable release of that sometime, RetroArch on Gentoo might be next up to bat. Let's see what the dismal future brings, friends. 🙉 |
|
Also, obligatory necrobump. |
|
It's not dead yet. |
|
That "10,000 commit" PR is not what it appears to be. IIRC, all PRs that were filed before our infamous GitHub hack ended up in this silly state. Perhaps most of them were closed automatically and we lost track. At least we have some of the cores in the tree now. I wasn't aware that @candrews lost interest. These things fall behind quickly. Although I have a passing interest in RetroArch myself, I'm already struggling with the day to day games issues. More manpower please. |
|
Hi yes oops I'm back @jason-oliveira have you made any progress on getting the RA stuff upstreamed? I was looking at diving into getting it running on my new RPi 4, and I finally remembered to check Github |
|
@IntelMiner not upstreamed, but stable ebuilds are being updated at my gitlab repo: The plan is to 1) update master overlay list with my repo, and 2) submit ebuilds upstream and watch them lose their minds at USE="-cores" being default. |
|
I should probably footnote that last point by letting people know that my repo uses cores built by RetroArch's buildbot, installed to userspace. As such, I have not updated all the individual cores. Considering RA builds for each arch Gentoo supports, this shouldn't provide too many issues. Feel free to launch hate and vitriol at me for this decision if you run into problems while I'm making this nice enough to upstream. |
|
@jason-oliveira If I'm understanding you correctly. You mean that your ebuilds simply install the pre-built RetroArch binaries from upstream? |
|
@IntelMiner Nowhere near that elegant. I just made a blatant "screw you, let retroarch manage that part in userspace" USE flag so that RA would install cores inside it's own manual downloader to wherever /etc/retroarch.cfg and/or ~/.config/retroarch/retroarch.cfg tells them. I personally prefer ~/.local/share/retroarch. Portage is completely out of the picture when it comes to installing an RA core. games-util/lutris (somehow upstreamed) does something similar for wine and libretro cores already, so a useflag to enforce this mode seems to be the best decision, at least short-term while preparing things for upstream (which will probably need all the old cores, plus all the new ones, as ebuilds). |
|
@jason-oliveira Fair enough. Are there any plans to break things out into their own source builds? I suspect what I'm going to be doing with RA is going to require patching cores and lots of fiddling. But the thought of writing an ebuild for every core is a nightmarish prospect |
|
@IntelMiner One would assume you do not have to disable USE="-cores" in order to build an individual core. The current plan is to steal liberally from this repo's (or @barbudreadmon 's) ebuilds for cores, and update them to current. An ebuild per core is required, and there have been lots of cores added to RA since @stefan-gr went AWOL. An easy flowchart (read: patches/pull requests welcome) would be: |
|
It's the same as with kodi pretty much, binary plugins are in separate ebuilds ( including retroarch cores ). Scripts are downloadable. |
Hello, I'm a Gentoo developer and I'd really like to see your work with libretro and retroarch enter the official Gentoo portage tree.
Would you be interested in creating PRs in the https://github.com/gentoo/gentoo/ repository for your work? If not, would you mind if I starting doing so?
Thanks!
The text was updated successfully, but these errors were encountered: