| Git Clone URL: | https://aur.archlinux.org/foobar2000.git (read-only, click to copy) |
|---|---|
| Package Base: | foobar2000 |
| Description: | An advanced freeware audio player (uses Wine) |
| Upstream URL: | https://www.foobar2000.org |
| Licenses: | custom |
| Submitter: | None |
| Maintainer: | supermario |
| Last Packager: | supermario |
| Votes: | 67 |
| Popularity: | 0.008924 |
| First Submitted: | 2010-05-07 18:02 (UTC) |
| Last Updated: | 2025-01-13 13:37 (UTC) |
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.
Can confirm that the change to 7zip broke the package in manjaro.
I think it would be better if we split the 32-bit version into a separate package called "lib32-foobar2000", per Arch package guidelines
@supermario Sorry, wrong link. I meant www.foobar2000.org/files/foobar2000-x64_v${pkgver}.exe (remove -x64 if needed).
I agree with @0RF30, it would be nice to keep using the 32-bit version.
(FWIW, changing the dependency from p7zip to 7zip breaks this package on Manjaro, where p7zip is apparently the only alternative.)
Pinned Comments
supermario commented on 2025-01-13 13:39 (UTC)
@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