Prebuilt stack packages

This page explains something you don't have to do — it's here so the speed doesn't surprise you, and so you know where the switch lives if you ever want to look behind the curtain.

Historically, installing or upgrading BOA meant compiling the heavy pieces of the stack from source code, on your box, every time: OpenSSL, the ICU text libraries, cURL, and every PHP version you selected. That's where most of an install's "long quiet stretches" came from — a single PHP version alone used to take many minutes of silent compiling.

On Devuan Daedalus — the recommended release for a BOA box — most of that work is already done for you. BOA publishes those same components as ready-made packages, built by BOA itself on its own build servers, and your box simply downloads and installs them. A PHP version now lands in seconds instead of minutes; the OpenSSL and cURL steps that used to compile for ten minutes or more finish almost instantly. Installs and upgrades both benefit, automatically.

Two things haven't changed, so you don't un-learn anything:

• What gets installed is identical. A package holds exactly what the source build would have produced — same versions, same layout. The packages are produced by running the real, unmodified BOA build and snapshotting the result; nothing is repackaged from third parties.
• The rhythm of an install is the same. Other phases (your Ægir control panel, PHP extensions, the background firewall pass) still take their time, so keep following the install guide's timings and don't interrupt a quiet stretch — there's just a lot less compiling inside it.

Nothing to set up

On Devuan Daedalus — the recommended install target — prebuilt packages are on by default. A fresh install uses them from the first minute, and you'll see lines like this in the install output or its log:

INFO: Prebuilt stack packages enabled by default on Devuan Daedalus
INFO: PHP 8.4.23 installed from prebuilt package

On other systems the default stays off until a complete package set for that release is published on the BOA mirrors; BOA then flips the default for that release in a regular update. Either way it's not your job to manage.

The safety net: automatic fallback

Every package install is verified against a checksum before anything is unpacked, and after installing, each component is health-checked before BOA moves on. If anything at all goes wrong on the package path — no package published for your exact version yet, a download problem, a checksum mismatch, a failed health check — BOA quietly does what it has always done: it compiles that one component from sources, exactly as before, and carries on. The worst case of the package path is simply the old behaviour.

The same is true for the PHP build on boxes with a customised build shape (for example a non-empty _PHP_EXTRA_CONF): the published PHP packages are built with shipped defaults only, so such a box automatically keeps compiling its PHP versions from sources — while the OpenSSL, cURL, and ICU packages, which that setting doesn't affect, still install normally. You don't have to configure anything for that to happen.

A pinned ICU version works the same way. Setting _ICU_FORCE_VRN (an advanced, single-box option) also counts as a customised build shape, because the prebuilt PHP packages link against BOA's default ICU — so a box that pins ICU automatically keeps compiling its PHP versions from sources too. As with _PHP_EXTRA_CONF, there's nothing to set: BOA detects the pin and takes the source path on its own.

This is why there is no troubleshooting section on this page: a package that can't be used never blocks an install or an upgrade. It falls back.

The switch

The behaviour is controlled by one setting in /root/.barracuda.cnf:

_USE_PREBUILT_PKGS=YES

You'll find it recorded there after a fresh Daedalus install. Our advice is the same as for the rest of the config: leave it alone. The only realistic reason to touch it is to set it to NO, which makes BOA always compile everything from sources — slower, but supported forever, and handy if you've been asked to rule packages out while debugging something. An explicit value you set here always wins over the defaults described above.

The switch never changes whether a component gets rebuilt — all of BOA's version checks and self-healing work exactly as before. It only decides how a rebuild happens: install the ready-made package, or compile.

If editing .barracuda.cnf is new to you, read Essential settings first — it shows how to change one line safely.

Curious what a run actually used?

You never need to check, but if you like to see what happened (or support asks), the run's report log tells you. Fresh-install logs live under /var/backups/reports/in/boa/, upgrade logs under /var/backups/reports/up/barracuda/, in dated folders. Each component that came from a package logs one line:

INFO: cURL 8.21.0 installed from prebuilt package

So this shows everything a run consumed as packages, whichever kind of run it was:

grep -r "installed from prebuilt package" /var/backups/reports/

A component that fell back either logs a NOTE: line saying it's building from sources (a package was found but something about it wasn't right — a download or checksum problem, an install error, or a failed health check), or — when no package was published for it at all — simply compiles without any special message, exactly like it always did. Silence about packages is normal, not a fault.

Related

• Install BOA — the install walkthrough whose quiet stretches this page just made shorter.
• Keeping BOA current — upgrades benefit the same way; the upgrade commands themselves are unchanged.
• Essential settings — how to edit /root/.barracuda.cnf safely, one line at a time.