Arch Linux User Repository

@aliu if you try to download the exe file directly in the sources array the download site returns you an HTML page not the actual executable so we need to do this workaround

all: I have updated this package to use the 64bit executable on 64bit systems now that the upstream 7zip package is able to extract it. If you have problems please report them and I'll rollback to the 32bit executable even on 64bit systems until we can find a fix

Is there a better place to put the foobar2000 installation files? Right now they get dumped in ~/.foobar2000 and this pollutes the home directory. Maybe $XDG_DATA_HOME/foobar2000 or ~/.local/share/foobar2000 instead?

point release. PKGBUILD needs be bumped to .2 and hashes updated

2c3cbf745bbd120d5f201d9ed91e9876880e26e2924770e76234855d1c8b2782 ~/.cache/pikaur/build/foobar2000/foobar2000-x64_v2.24.2.exe 35c5465221c77d469dde411c6a5bc1b52509960b554fbf6ba76824a6d5554bd9 ~/.cache/pikaur/build/foobar2000/foobar2000_v2.24.2.exe

@cammera See https://wiki.archlinux.org/title/Wine_package_guidelines and https://wiki.archlinux.org/title/Arch_package_guidelines#Directories . TL;DR: Portable means you can just extract the files. Per Arch package guidelines, each package should be in its own directory somewhere under /usr/. Not portable means you have to create a ~5MB wine prefix for each package due to Arch's filesystem hierarchy.

TL;DR: It's just how Arch and Linux in general is organized.

Why exactly does this set the install to portable mode? A regular install is significantly easier to manage and update, and doesn't require the user to run root to do so. There's no benefit from mixing the install and the user data that I can see.

64-bit memory management is way more efficient and speedy. There's also overhead in using WOW64 and emulating WOW64 under a Linux machine.

Maintaining a package is probably easier than you think: it's nearly as easy as using Bash. I'd make the package myself if I wouldn't be maintaining a package I don't use.

Unfortunately, I'm not competent enough to maintain a 32 bit package, but it would be really nice if you or someone else could do this, as the 32 bit version has the widest plugin compatibility, plus there is no real benefit of running 64 bit over 32 bit.

Could you consider changing the find ... -execdir command to use -exec instead? -execdir fails when there is a relative path in PATH. I know this is mostly a me problem, but -exec seems to work anyways.

For manjaro users I'm sorry but the official arch guidelines are that the AUR is for Arch linux. You should poke the manjaro maintainers to replace p7zip with 7zip like has already happened on arch and other distributions (like debian).

As for a 32bit build, I could make this a split-package that always uses the 32bit executable, but on 32bit systems it would create two identical (if differently named packages). Alternatively, I (or someone else as I'm unlikely to use it) can maintain a 32bit-only package. I don't believe that it would be against the AUR guidelines

@aliu thanks for the tip, I'll switch the sources over on the next release

That it breaks in Manjaro is not too much of a problem IMO. The AUR is supposed to be understood, just like the Arch philosophy, and Manjaro should just "port" in the new 7zip package already. It's been 3 weeks.