You are not logged in.
I've noticed over the last few years it's become increasingly popular for packages that ship with AppImages to end up on the AUR, merely extracted as is.
Wouldn't it be better to use the traditional standard of offering a binary compiled from source? Using AppImages is convenient for package maintainers, I suppose, but isn't this bringing in unnecessary dependency bloat that could otherwise be avoided?
Offline
How else would you prefer the "-bin" version of a package to be provided? Because compiling it from source wouldn't be a "-bin" version of that package, but named without "-bin". By definition, the "traditional standard", as you define it, isn't a "-bin" package.
Offline
I don't know what you're trying to say. In the past, -bin packages were created from binaries that were compiled from source. It is still how -bin packages are done for packages that don't ship with AppImage variants.
Edit: clarified wording
Last edited by hypnagogic (2025-08-28 23:47:38)
Offline
If the only binary upstream provides is the AppImage that's going to be the bin that gets repacked. There's not much say in that that any AUR maintainer can make.
Offline
In the past, -bin packages were created by compiling the binaries from source. It is still how -bin packages are done for packages that don't ship with AppImage variants.
That is never, ever how -bin packages were created.
Offline
-bin packages use pre-compiled binaries , whether those come from a rpm , deb , tar.gz or appimage doesn't really matter .
If the sources of the packages are available, using -bin packages typically is a bad idea.
There are some cases where creating a -bin package even if the source is available has merits .
An example is software that comes with a pre-compiled deb that relies on debian-specific behaviour in dependencies (without mentioning that) .
Canon printer drivers suffer from that, which is why both cnrdrvcups-lb and cnrdrvcups-lb-bin are in the aur.
EDIT
TL;DR: using aur *-bin pacakges is less then optimal .
Last edited by Lone_Wolf (2025-08-30 12:24:29)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline