Talk:Nonfree applications package guidelines

DLAGENT no workaround

It looks like there is a workaround for bash arrays, and it is implemented here: https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=decklink-sdk aviallon (talk) 20:39, 4 May 2021 (UTC)

RPM vs DEB for repackaging

If the proprietary software is provided in both ".deb" and ".rpm" package files, should one or another be prefered? I often see deb packages been repacked, but want to understand if there is any reasoning behind that.

For the case with Davinci Resolve, the reason may be that it is packaged for CentOS vs Ubuntu, and Ubuntu has more recent versions of software, so probability that software will work with with Arch Linux is higher. That is understandable.

But for other cases, I see (for now) no obvious reasons to prefer one or another. Ashark (talk) 10:54, 5 November 2024 (UTC)

One technical point to prefer RPM is that it's easier to unpack. When makepkg unpacks RPM, you have its content directly.

In contrast, DEB contains another archive data.tar.xz inside, which you need to unpack the second time manually.

But beside that, the end result is the same, there is no real difference. It's a matter of package maintainer's preference and/or quirks of a particular package.

Hanabishi (talk) 14:25, 5 November 2024 (UTC)

But with deb, you have direct access to extra files like postinst and package description/version, while with rpm you must have special utilities, right? Ashark (talk) 17:29, 9 November 2024 (UTC)

I have no idea why you ever would need that. PKGBUILD already contains package version and description. And Debian postinst scripts are pretty much useless on Arch.

Hanabishi (talk) 17:46, 9 November 2024 (UTC)

At least to see whats in there. Also, I may want to use a specific pkgver function to extract package version. Because sometimes, the package in download link does not have version in its name. For example like this app. I guess it is somehow possible to parse the repo files (they add repo urls internally), but other than that, need to extract it from control file. Ashark (talk) 17:56, 9 November 2024 (UTC)

I think that falls under

package maintainer's preference and/or quirks of a particular package

Hanabishi (talk) 18:16, 9 November 2024 (UTC)

I would like this be covered in the article. And also, have the example for rpm package (which is missing at the moment of writing). Ashark (talk) 08:56, 13 November 2024 (UTC)

>Ubuntu has more recent versions of software, so probability that software will work with with Arch Linux is higher.

If Fedora Rawhide build is avaiable (rare for nonfree apps?), worry about ABI compability may smaller than .deb . oech3 (talk) 06:53, 24 April 2025 (UTC)

Non Full RELRO, LD_BIND_NOW=1

It may nothing to do by packaging side. Is Gaming#Load_shared_objects_immediately_for_better_first_time_latency useful for non Full RELRO binary? oech3 (talk) 09:38, 15 April 2025 (UTC)

Extracting .snap, .flatpak

Really nonfree archive with them may rare.But,

7zip for .snap is sometimes used. Is it always collect? oech3 (talk) 09:45, 15 April 2025 (UTC)

This is a guidelines page – it should not contain all practices, only the best practices. Both Snap and Flatpak can be used on Arch, so repackaging their applications for Arch seems like a useless exercise that also avoids the sandbox features. — Lahwaacz (talk) 04:31, 18 April 2025 (UTC)

I completely agree with Lahwaacz’s points about guidelines and the merits of sandboxing. I don’t think re-packaging snaps/flatpaks is entirely useless per se though, especially due to dependency bundling.

Flatpak/snap builders are not system package maintainers. They’re upstream project authors wielding a packaging toy.

The effects of this might not be entirely offset by sandboxing. Things that might be a no-brainer for system package maintainers, your typical upstream project author isn’t going to do. They lack the experience and the resources that system package maintainers have. They don’t have access to private security mailing lists, which means they don’t get to prepare patches in advance for a critical vulnerability in one of their bundled dependencies. Not that an upstream author would bother; they’re a project maintainer. Many upstream folks don’t bother cutting new releases just because a critical security patch in one of their bundled dependencies is available. What they do is bundle a snapshot of whatever their dependency tree happens to be at the point in time they cut their release and call it a day.

For similar reasons, I can see why a risk-averse distro user would want to avoid packages based on Node.js (no system package maintainer can possibly unbundle 10.000 dependencies), Rust (has static linking in their DNA), and Java (unless you’re a scientist working on a thesis about how many fat jars can recursively fit inside each other.) — Auerhuhn (talk) 09:01, 18 April 2025 (UTC)

@Auerhuhn @Lahwaacz how about moving Unpacking section to another place? oech3 (talk) 06:44, 24 April 2025 (UTC)

Strict rule when to use -bin suffix

Currently, the rules for using "-bin" suffix for non-free software is not strict.

Let us assume I am packaging "Yandex Music" application. It does not have sources and never will. It is available in the form of .deb package. Now, I want to add it to AUR. What name should I use for the pkgbase? Currently, the wiki page says:

If you are certain there will never be a source-based package, you can omit the suffix -bin. Otherwise, always use this suffix.

That sentence clearly leaves the choice to the packager. It says "you can omit", but not exactly "must omit". This creates a gray zone, where it is not clear if the "yandex-music" or "yandex-music-bin" should be considered the correct name. Which can lead to argues when making the aur namespace consistent.

I propose we have a strict rule when to use "-bin". The rule may be like this:

For non-free software, if the sources are not available, the "-bin" suffix should not be used. Existense of "-bin" suffixed package in the AUR means that there should be a corresponding package without "-bin" in the AUR or in Official Repositories.

Example packages of proprietary software which are not using "-bin": discord.

Please comment on the proposal. Ashark (talk) 22:07, 28 October 2025 (UTC)

"There should be" may be wrongly interpreted as "the -bin package owner should create." I would suggest changing it to "there is the potential to have." Also, should the non-bin package provive the -bin package? 1F616EMO (talk) 17:48, 2 November 2025 (UTC)

Yeah, such clarification makes sense. So, the rule may be like this:

For non-free software, if the sources are not available, the "-bin" suffix should not be used. Existense of "-bin" suffixed package in the AUR means that there is the potential to have a corresponding package without "-bin" in the AUR or in Official Repositories.

Regarding if a non-bin package should provide the -bin package: definitely no. It is opposite, the -bin packages may/should provide the non-bin package. Ashark (talk) 22:59, 2 November 2025 (UTC)

I'd rather propose to use the -bin suffix whenever a precompiled binary is being installed, no matter if there is (or will possibly be) a package where the compilation process takes place while building the package on the user's machine. That is, a -bin package can exist even if there is no "no-bin" package, the suffix just informs the user that he is installing a precompiled binary. PhotonX (talk) 20:32, 2 November 2025 (UTC)

I agree. Aaron Liu (talk) 21:03, 2 November 2025 (UTC)

Agreed; the original proposal's focus on free vs proprietary software should be irrelevant (in particular, a nonfree package that builds from public sources being named `-bin` would be confusing and misleading). SudoBash418 (talk) 21:53, 2 November 2025 (UTC)

The proposal says "if the sources are not available": free vs proprietary is just the common case but source available software is handled. Erus Iluvatar (talk) 07:37, 3 November 2025 (UTC)

I disagree. While at first, it may sound like a clear rule, in practice, this means that lots of packages should have the -bin suffix. That would be really annoying. And the official repositories do not use that approach. Take in mind packages such as xxxx-firmware, nvidia-xxxx, discord (in official repo, not using -bin), pycharm (aur package, built from pre-built binaries), and so on.

Think of a -bin suffixed package as a "lazy" build of a package when normal build of a package is possible. Ashark (talk) 23:19, 2 November 2025 (UTC)

Why would it be annoying, or more annoying than Moderators needing to check whether the package has sources available to determine whether to remove the -bin? I have no problems with having the official repos have -bin names in packages as well.

I don't see why that's what we should think of it as; see my reply below. Aaron Liu (talk) 23:40, 2 November 2025 (UTC)

Because it's a reversal of the status quo: that means we're creating a bunch of busy work for no clear benefits. Erus Iluvatar (talk) 07:29, 3 November 2025 (UTC)

We would be creating a bunch of busy work if either variation of the proposal is implemented (either the original "always drop -bin if sources aren't available" or "always add -bin no matter source availability", not that it must be implemented. And on the subject on that work, the latter variation would be easier to busywork over since it doesn't involve the extra step of checking for source availability. Aaron Liu (talk) 05:21, 4 November 2025 (UTC)

I don't recall seeing many -bin packages where source is unavailable, but I'd be happy to be wrong. Have you considered applying for the AUR moderator role when it gets implemented to help with the busywork?

-- Erus Iluvatar (talk) 07:48, 4 November 2025 (UTC)

Official repositories include binary packages only, they are never compiled on the user's machine, so of course it makes no sense to add a -bin suffix to all of them.

I don't think that there is a large number of AUR packages that currently have no -bin suffix despite of being binaries, because there is no "no-bin" package, and would get a -bin suffix according to the proposed rule. We are speaking about a corner case which is not fully defined, so the number of affected packages should be rather small. PhotonX (talk) 09:47, 3 November 2025 (UTC)

No, actually, almost all such packages do not have -bin suffix. I can name lots of examples: google-chrome, vivaldi, bcompare, spotify, wps-office, sublime-text-4, dropbox, yandex-disk, slack-desktop, zoom, etc. Imagine all of these packages would need to use -bin suffix. That would be just an inconvenience. Ashark (talk) 10:53, 3 November 2025 (UTC)

Existense of "-bin" suffixed package in the AUR means that there is the potential to have a corresponding package without "-bin" in the AUR or in Official Repositories.

Why? Doesn't the same go for source-availiable packages built from source and thus without -bin in their name? Aaron Liu (talk) 23:41, 2 November 2025 (UTC)