Filesystem Hierarchy Standard: MAME is a MESS

d.ALT · 2022-10-20 12:07:14

I know I know, FHS is a reference describing the conventions used for the layout of a UNIX system. (taken from WikiPedia)
Fine by me, OK.

But... Why M. A. M. E. (and RetroArch also, for example) is split between /usr/lib/mame and $HOME/.mame?

OK, some of you may rightly point out that is M. A. M. E. itself so weird, I get it.

But, personally, I find myself to be much more comfortable in manually compiling M. A. M. E. and slamming all of it (executable included) into $HOME/.local/share/MAME and configuring its paths accordingly.

What do you think?

V1del · 2022-10-20 12:17:11

Not exactly sure what you mean here? I don't see the logical clash. /usr/lib/mame is for system-wide modules/configs and $HOME for user specific.

Threre's no reason retroarch or mame need to "split" themselves. It's simply more convenient on your one user system to not have to worry about a system path you might need to change ownerships for. E.g. if you stick to the packaged cores with retroarch the only thing in your user home would be your user specific config like save files and configuration and the like, while cores live system wide.

You "always" need to think in the context of a multi-user system as for why the splits are the way they are. If multiple users are using retroarch then a different user from yourself might want to have different settings/different game progress while sharing the shareable parts/executables.

Last edited by V1del (2022-10-20 12:17:47)

Trilby · 2022-10-20 13:53:11

Mame and retroarch are not rarities in this regard: a majority of software will create / use content under $HOME. And that's the way it's supposed to be. The FHS outlines where different types of content should go for the very reason that projects / packages will be split among different locations with their binaries in one places, the shared libraries another, artwork and documention in another, and configs and user date yet elsewhere. That's the point.

The FHS doesn't say "pick one of these locations and slam everything from your project together there." That's a windows approach and perhaps flatpak approach. And it sucks.

Look at any package in the repos and you'll see they contain content that is distributed across various parts of the filesystem. Look under your home directory (or gradually this is being improved to focus on ~/.share ~/.config, etc w/ the XDG specs) and you'll see content associated with countless repo packages.

d.ALT · 2022-10-20 19:28:52

@V1del @Trilby, thank you for answering me.

Trilby wrote:

The FHS doesn't say "pick one of these locations and slam everything from your project together there."

I never said that, neither thought about it.

It's always difficult for a non-native english speaker to explain concepts / ideas... So, please be patient and let me try to better explain my doubts.

Here's some examples:
- for me, the main "issue" here is "going outside" $HOME

- with Dolphin Emulator (and RPCS3) I never felt the urge to "go outside" $HOME: everything I need to look at is $HOME/.local/share/dolphin-emu and $HOME/.config/{dolphin-emu,rpcs3}

- RetroArch won't be able - by default - to dowload assets / cores until the user manually declare paths-with-${whoami}-permissions inside .config/retroarch/retroarch.cfg
- Maybe user A wants different things than user B. Eg: why assets are declared inside a non-writeable path assets_directory = "/usr/share/retroarch/assets"?
- From my perspective is more comfortable to let RetroArch handle all the users needs from within itself (since RetroArch can do this), rather then installing community/retroarch-assets-ozone, community/libretro-pcsx2, community/libretro-mame, etc...

- In M. A. M. E. different users maybe will have different games and so different atworks also (artworks is - I think - a user preference). So, why having /usr/lib/mame/artwork/ insetad of $HOME/.mame/artwork or $HOME/.local/share/MAME?
- On the contrary, I think paths like /usr/lib/mame/language or /usr/lib/mame/plugins are in the right place to be available system-wide and the user(s) won't have needs to modify the contents.

Trilby · 2022-10-20 19:55:32

d.ALT wrote:

- On the contrary, I think paths like /usr/lib/mame/language or /usr/lib/mame/plugins are in the right place to be available system-wide and the user(s) won't have needs to modify the contents.

So you agree that putting different types of resources in different locations makes sense. It seems your concern is not that these programs keep resources in different locations, but you think some specific resources are in the wrong place. That makes sense. But at least in the case of retroarch you note that the location these are stored / downloaded is configurable by the user - so just configure your preference.

d.ALT · 2022-10-20 20:30:00

Hey Trilby.

Yup, my concerns are about some paths that users will likely need to work within. So why some programs are not packaged by default with that paths set inside $HOME?

Also, have a look at mame.ini inside $HOME/.mame: there are references that point at $HOME/.mame, $HOME/.mame/ini, $HOME/ui and /usr/lib/mame.
User will have mame.ini doubled in both $HOME/.mame and $HOME/.mame/ini, the exported lists will be - by default - saved into $HOME/ui, references dats for Systems (SoftwareList, ex M. E. S. S.) are found into /usr/lib/mame/hash instead.

That's lead to some confusion!

OK, no problem configuring these paths manually by hand, but - hey - it's somewhat strange!
All this seems anomalous to me, other programs do not behave like this.

That's why I ended up slamming everything of M. A. M. E. inside $HOME/.local/share/MAME (with the only exception of roms and samples being bind-mounted from my NFS share into $HOME/.local/share/MAME/{roms,sanples}).

seth · 2022-10-20 20:45:58

You do fundamentally not understand how POSIX systems operate.
Or you're trolling.

Local files, eg. in the $HOME or $XDG paths (but also /usr/local and even /etc) will augment or shadow the global files in eg. /usr/*
That's not specific to MAME, that is the core design of UNIX and then POSIX systems since the dawn… well, 1969, and not confusing to anyone who understands why the windows approach is a very unfotunate heritage from DOS.

Everything in front of you operates on that principle and every exception to that rule is an exception and likely indicative of some stupid kludge going on.

d.ALT · 2022-10-20 21:15:35

seth wrote:

every exception to that rule is an exception and likely indicative of some stupid kludge going on.

Is this referred to the mame.ini files or to me putting everything into .local/share/MAME?

seth · 2022-10-20 21:41:16

This refers to binary only release, windows programs and to some extend snapflatdocker.

Looking at what mame actually does, it seems to be a windows influenced single-dir approach that, but for the documentation, completely resides in /usr/lib/mame - so it would fall into that category.
You can however utilize https://man.archlinux.org/man/community … th_options to make it operate more like traditional unix applications and the /usr/bin/mame script seems to do exactly that:
https://github.com/archlinux/svntogit-c … nk/mame.sh

having /usr/lib/mame/artwork/ instead of $HOME/.mame/artwork

Because pacman (packages in general) will and cannot install stuff into $HOME - and this isn't a XOR situation.
You have /usr/lib/mame/artwork AND $HOME/.mame/artwork

d.ALT · 2022-10-20 22:08:36

seth wrote:

/usr/bin/mame script seems to do exactly that:
https://github.com/archlinux/svntogit-c … nk/mame.sh

This helped a lot, here's the catch! Got it!
That's why M. A. M. E. was behaving so strangely to my eyes: it's a script, rather than the executable itself!

$ file /usr/bin/mame
/usr/bin/mame: POSIX shell script, ASCII text executable

$ file /usr/lib/mame/mame
/usr/lib/mame/mame: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=88fa1b1ce2c0fd600d9bb0a8b1a56c653d00b726, for GNU/Linux 4.4.0, stripped

Thanks seth, you helped me in clearing out the fog.
Now I understand why M. A. M. E. is "split" into different paths!!

P. S.: now another question arises, why isn't M. A. M. E. packaged so that the actual executable is actually installed into /usr/bin/mame?

EDIT: grammar+typo

Last edited by d.ALT (2022-10-20 22:18:02)

seth · 2022-10-20 22:15:07

As mentioned, this seems to be some windows influence (MAME is a cross-platform emulator)
The code by default expects its hierarchy next to the mame binary, ie. if /usr/bin/mame was the binary, it'd look for eg. /usr/bin/artwork

And MAME isn't "split into different paths" - quite the contrary. At least by default.
It's the script (and possibly config files) that explicitly align it w/ a traditional unix appraoch.

d.ALT · 2022-10-20 22:23:30

seth wrote:

ie. if /usr/bin/mame was the binary, it'd look for eg. /usr/bin/artwork

And this is not conformant as it would break the FHS standard.
Understood!

d.ALT · 2022-10-20 22:29:48

seth wrote:

It's the script (and possibly config files) that explicitly align it w/ a traditional unix appraoch.

OK, the script is some sort of "workaround".

Are there any other examples - in Linux - of programs that need to be launched via a /usr/bin/SCRIPT?

Trilby · 2022-10-20 23:36:54

d.ALT wrote:

Are there any other examples - in Linux - of programs that need to be launched via a /usr/bin/SCRIPT?

Lots of them. Around 215 on my system:

$ file /usr/bin/* | grep script | wc -l
215

But lots of these aren't due to FHS issues. There are lots of reasons to use a wrapper script.

Arch Linux

#1 2022-10-20 12:07:14

Filesystem Hierarchy Standard: MAME is a MESS

#2 2022-10-20 12:17:11

Re: Filesystem Hierarchy Standard: MAME is a MESS

#3 2022-10-20 13:53:11

Re: Filesystem Hierarchy Standard: MAME is a MESS

#4 2022-10-20 19:28:52

Re: Filesystem Hierarchy Standard: MAME is a MESS

#5 2022-10-20 19:55:32

Re: Filesystem Hierarchy Standard: MAME is a MESS

#6 2022-10-20 20:30:00

Re: Filesystem Hierarchy Standard: MAME is a MESS

#7 2022-10-20 20:45:58

Re: Filesystem Hierarchy Standard: MAME is a MESS

#8 2022-10-20 21:15:35

Re: Filesystem Hierarchy Standard: MAME is a MESS

#9 2022-10-20 21:41:16

Re: Filesystem Hierarchy Standard: MAME is a MESS

#10 2022-10-20 22:08:36

Re: Filesystem Hierarchy Standard: MAME is a MESS

#11 2022-10-20 22:15:07

Re: Filesystem Hierarchy Standard: MAME is a MESS

#12 2022-10-20 22:23:30

Re: Filesystem Hierarchy Standard: MAME is a MESS

#13 2022-10-20 22:29:48

Re: Filesystem Hierarchy Standard: MAME is a MESS

#14 2022-10-20 23:36:54

Re: Filesystem Hierarchy Standard: MAME is a MESS

Board footer