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)