[SOLVED] PPA reinstall: Assets don't work, uses /usr/share/libretro?!

RetroArch Linux devices
#1

Hey guys, I wanted a clean fresh start with RetroArch because I was experiencing some issues with some games. So I uninstalled RetroArch:

  • sudo apt remove --purge retroarch
  • sudo apt autoremove
  • sudo rm -r ~/.config/retroarch

After a reboot, I installed RetroArch from the PPA (and later again from the Testing PPA) and when I started it for the first time, I immediately noticed that it was on the XMB menu. I thought the default was Ozone now, and it’s also the menu I get when I do a fresh install on Windows. So that confused me, but okay.

More oddly, when I download Assets using the Online Updater, nothing happens. I’m used to the RetroArch window quickly refreshing, but this doesn’t happen and the fonts aren’t loaded either:

image
image960×756 135 KB

Oddly enough, the icons seem fine.

I also noticed that the default directory for Assets is /usr/share/libretro/assets, which is completely wild. Why? This directory is not writeable by normal users, only root. And yet, I find an “assets” and an “info” directory in there.

I guess I’m kind of out of the loop about how RetroArch works, I haven’t completely reinstalled it in a while. Can anybody let me know what’s the correct way to proceed from here?

#2

Hmm. Main Menu > Configuration File > Reset to Defaults seems to have fixed the issues.

1 Like
#3

Yeah, we got a new guy working on the PPA debianization who does official packaging for some distros, I think. He’s made some changes–like the ones you mentioned–that I don’t love from a RetroArch perspective, but it seems it’s making the distro packages closer in function to the PPA (i.e., instead of being completely different), which is for the greater good, IMO.

1 Like
#4

Thanks for following up, @hunterk. But doesn’t it break RetroArch if some default directories are in /usr/shared, which is not writeable? I don’t think users want to or should have to run RetroArch with admin privileges. What am I missing? Thanks :slight_smile:

#5

You can still point it to user-writeable directories, as you’ve found, but I think new dude is looking to beef up the packages accordingly. Dunno if that’ll mean more core packages or what. We’ll see, I guess. If needed, we’ll just revert back to the original behavior.

#6

Thanks! This context helps me understand it better. Good to know the workaround in the meantime. :slight_smile:

#7

It’s not wild at all, it follows debian policy.

Broadly speaking, all updates to an app in debian should be handled by the package manager and not the app itself (for security reasons etc.). For RA this means packaging assets, cores, etc. Some maintainers may even patch out the ability to update and load binaries (like cores) from user-writable locations.

Fortunately RA is rather easy to build from source to fit your needs.

2 Likes
#8

I’d argue that opens up a new set of questions.

  • If I go to Settings > Directory in RetroArch, I see over 30 directories. Wouldn’t it be consistent to place all of that in /usr/share by default? Why only Assets and Info files?
  • Since it’s impossible to use the Online Updater on Linux if assets, cores etc. are stored in a directory that’s read-only for normal users, shouldn’t the Online Updater be disabled on the Linux version altogether?
  • If we keep the Online Updater, shouldn’t there be a warning to users that they need to run RetroArch with root privileges to use it?
  • Is there a guarantee that Linux users will be able to get the latest versions of cores, assets etc. from the PPA? I’ve always trusted that the Online Updater would be the best way to get all the latest stuff.
  • When installing RetroArch for the first time, it comes with incomplete assets installed alongside it right from the PPA. Check out the screenshot in my first post, the fonts for XMB are missing. Since this is all that’s available from the PPA, users have no easy way to get the correct fonts (since the Online Updater doesn’t work). That causes confusion. So this question ties back into my previous question: how can we make sure that users always get the latest, and complete, data from the PPA?

Bear in mind, I’m using the latest nightly so I assume everything here is WIP and I’m genuinely curious about the answers to these questions.

It looks to me like RetroArch currently isn’t working very well on Linux out of the box and it needs to be fixed. Here’s a video showing what I mean: https://youtu.be/wnWWkA1KFo0

I promise to open a proper bug report about this on GitHub as soon as I can, but I need to get back to work for now. :slight_smile:

1 Like
#9

Since you’re already using Linux Mint, why don’t you try out the (also official) flatpak or appimage versions? They’re more compatible with how RetroArch operates, since native packages have tight restrictions for security and stability reasons. You’d get the latest updates straight from the app and wouldn’t have to worry about directories.

1 Like
#10

Alright. Bear in mind that what I wrote is what debian wants in an official package and does not refer to Linux as a whole. Also I put debian as an example, every distro has its own policies.

IMO it’s for things for the app to run, such as assets, cores and info files. Other things are user generated such as saves, etc.

On the official debian package it indeed might be disabled, I haven’t checked. But yes.

No, RetroArch upstream has no need to follow whatever debian wants.

Personally I don’t think that there is any guarantee, the PPA is a volunteer effort. I always build from source anyway.

The build process for the PPA probably just needs some tweaks.

1 Like
#11

So, like almost 15 yrs ago, I started the PPA with the intention of making packages that were compatible with debian packaging conventions to get them into the official repos. That worked out, more or less, but just like the current situation with distro packages, it was a hassle to use RetroArch the way we want it to work.

So, we reworked how all of the packaging and recipes worked and completely ignored all packaging conventions. This was nice because everything could run through the online updater as we like it, but since it doesn’t come with anything, someone installing for the first time is left with what essentially amounts to a semi-broken system. That is, no assets, no fonts and no clear path to fixing it, unless they already know they need to get into the online updater and fetch everything.

It also left distro packages in a tight spot because they needed to do a lot of patching and finagling to shoehorn our stuff into their packaging conventions, with no guidance from us as to how the pieces fit together. That is, they couldn’t just look at our PPA and say “oh, that’s what an asset bundle needs to include,” for example.

Nowadays, we have the snap/flatpak and AppImages, which provide an out-of-the-box system with all of the stuff you need to get started while also working with the online updater. This gives us some room to make the PPAs function more like official and up-to-date distro-style packages, though that requires some changes to how people are going to interact with the program–which has already been happening with the unofficial (to us; official to the distros) distro packages in the debian/ubuntu repos and AUR, etc.

Now, to be clear, this isn’t some grand design that we planned out and discussed, but these are my reasons for not just undoing the changes that the new guy’s been implementing (that is, alongside the other necessary work he’s been doing of just updating the recipes to keep up with the changes to the launchpad build farm, etc., which I haven’t touched myself in years, so the help is welcome).

3 Likes
#12

Thanks, you’re right, those are good points! I’ve used them in the past and can’t remember why I went back to PPA. Makes sense.

#13

Awesome, thanks for the context! Very interesting situation. I wish I was better at programming so I could contribute more. RetroArch is one of the most awesome pieces of software I know.

1 Like