Arch Linux

grain_collector

Member

Registered: 2022-06-06

Posts: 1

What are the pros/cons of using -bin packages instead of the defaults?

(I tried to duckduckgo and search this forum for answers, but unfortunately the syntax of "*-bin" alongside other keywords provided next to no answers.)

I already know that -bin designates a package that has already been prebuilt before the user downloads and installs it. The "pros" of this are that this mitigates end-user cpu time and energy costs (I would imagine that on a large enough scale, the energy savings could potentially be beneficial). I also know a "con" of this is that if you've installed a -bin package, you no longer have a local copy of the source code so you can't readily read/edit it.

So besides the above, are there any other reasons to install one or the other, or is that all there is to it?

Whoracle

Member

Registered: 2010-11-02

Posts: 40

Re: What are the pros/cons of using -bin packages instead of the defaults?

Everything below heavily In My Experience. Please use your own common sense.

Con:

• -bin packages are more often than not (IME, at least) "repackages" from other distros. For example, the PKGBUILD downloads a .deb, unpacks it and copies the files somewhere. This leads to potential issues if the package originates from Distros that are somehow incompatible with Arch. The most common Issue I have experienced is incombatible library dependencies: Say package foo depends on libbar 1.23 in Debian, but Arch being rolling release is at libbar 1.36

• You are running a precompiled binary from $somewhere on your system, not vetted by either yourself (which you could do when it's built from source) or one of the trusted maintainers

Pro:

• Resource Usage on your ssystem goes down

• Install times go down

• System Update times go down

For me personally, the last Pro is what leads me to use -bin packages from AUR. For example azure-cli takes ages to install/update on my Ryzen 7800X3D, and since I fully -Syu my system every night before shutdown, this kinda sucks. Given the choice, I usually install the regular version first, and if I see that it gets frequent updates that take ages, I switch to a -bin package.

That being said, the amount of -bin packages on my daily driver system is still pretty small, given that I need quite a lot of tools for work. These are all I have installed:

local/powershell-bin 7.4.1-1           # takes ages to build/update, and builds regularly fail, because microsoft can't do dependencies
local/audiobookconverter-bin 6.1.0-1   # is only available as -bin
local/azure-cli-bin 2.56.0-2           # takes ages to build/update, and builds regularly fail, because microsoft can't do dependencies
local/m4b-tool-bin 0.4.2~20230214-2    # is only available as -bin
local/openlens-bin 6.5.2-2             # is only available as -bin
local/rancher-cli-bin 2.8.0-1          # is only available as -bin
local/rancher-k3d-bin 5.5.2-1          # had some compatibility issues, and also takes ages IIRC
local/sensuctl-bin 6.4.3-1             # is only available as -bin
local/telegraf-bin 1.29.1-1            # don't rightly remember why I chose the -bin
local/terraform-docs-bin 0.16.0-1      # don't rightly remember why I chose the -bin
local/tflint-bin 0.50.2-1               # had some compatibility issues and I didn't havce the nerve to investigate
local/unreal-engine-bin 5.3.2-1        # regular package out-of-date, and well, I have to download the zip anyways, so...
local/yay-bin 12.2.0-1                 # see below

And looking at them, I could probably excise at least 5 of them, and possibly way more.

The only one I'd actually recommend if you are using yay: Having it precompiled sometimes precludes dependency issues. However, on my servers I switched to a package in my own repo that I periodically rebuild. I just like to keep my desktop "isolated" so if something goes wrong I can fix it.

ayekat

Member

Registered: 2011-01-17

Posts: 1,599

Re: What are the pros/cons of using -bin packages instead of the defaults?

Hi and welcome to the forums!

I assume you're talking about the PKGBUILDs in the AUR?

The "pros" of this are that this mitigates end-user cpu time and energy costs (I would imagine that on a large enough scale, the energy savings could potentially be beneficial).

I would imagine that on a large scale, most people will set up a local package repo and push built packages there, to be installed from the client systems.
So the steps of building and installing are split, and (1) whoever builds the packages won't have to care about how many clients there are, and (2) the end user actually won't have to care about any of the buildtime issues.

I also know a "con" of this is that if you've installed a -bin package, you no longer have a local copy of the source code so you can't readily read/edit it.

If it's FOSS, the sources are likely available somewhere; they simply aren't fetched by makepkg as part of the package building process. I wouldn't necessarily consider this a "con".

IMO one "pro" is that you're dealing with software as built and distributed by the upstream project, thereby facilitating interaction with them for troubleshooting/support.
Also I assume you (--edit: and Whoracle) are looking at a case with just one PC where you don't care much about scaling the package building process (paragraph above), so one gain is that you save compilation time.

A "con" is that it may not integrate with the OS distribution that well (as skilled as many developers may be, sadly most of them are rather bad at understanding downstream/distributions), and you may run into trouble there (--edit though admittedly this can be mitigated to some degree by a skilled packager).
Also you're trusting whoever built the software (you already do for your distribution, but now you're expanding the set of people you have to trust, which is probably a negative).

Last edited by ayekat (2024-01-31 12:17:04)

---

pkgs │ hacks │ cfg │ blag

Stefan Husmann

Member

From: Germany

Registered: 2007-08-07

Posts: 1,391

Re: What are the pros/cons of using -bin packages instead of the defaults?

I think it is not easy to find a comprehensive pros/cons list here, because the list differs from usecase to usecase or - better said - the undelying technology. E.g. some of the cons vanish for packages that depend on the rust- or go-toolset, because these technolies enforce static linking, so the binary you compile yourself and the binary you get from the -bin-package are pretty much the same.