Skip to content

build(llard): install autotools dependencies - #189

Open
MeteorsLiu wants to merge 1 commit into
xgo-dev:mainfrom
MeteorsLiu:ci/install-autotools-tools
Open

build(llard): install autotools dependencies#189
MeteorsLiu wants to merge 1 commit into
xgo-dev:mainfrom
MeteorsLiu:ci/install-autotools-tools

Conversation

@MeteorsLiu

Copy link
Copy Markdown
Collaborator

Equip the llard runtime image with the GNU source bootstrap tools required by Formula builds.

The implementation includes:

  • Install autoconf, automake, and gperf for projects that generate Autotools build files from Git source checkouts.
  • Install groff for upstream documentation generation and patch for gnulib bootstrap steps.
  • Keep the tools in the final Debian image alongside the existing compiler, CMake, Git, and pkg-config toolchain while retaining --no-install-recommends and apt-list cleanup.

This allows llard workers on both published Linux architectures to build packages whose repositories omit generated configure files.

@codecov

codecov Bot commented Sep 3, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@fennoai fennoai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review: add autotools build tools to llard image

The change adds autoconf, automake, gperf, groff, and patch to the runtime image's apt install list. This is consistent with the purpose of llard: it's the build daemon that shells out to build tools (via execbroker) to compile C/C++ libraries from source formulas at runtime, so autotools-based formulas (autoreconf, patch application, perfect-hash generation) need these present. Placement is correct, alphabetical ordering is preserved, and the existing hygiene (--no-install-recommends, cleanup of apt lists, non-root user) is kept.

Two minor, non-blocking notes below. No blocking issues.

Note: several review heuristics flagged "build tooling in a runtime image" as an attack-surface concern. That premise doesn't hold here — executing build tools at runtime is the daemon's core function, not an anti-pattern — so it's intentionally not raised as a finding.

Comment thread cmd/llard/Dockerfile
cmake \
git \
gperf \
groff \

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P3] Consider groff-base instead of full groff

groff pulls in a fairly large typesetting/documentation stack. If it's only needed so source builds can regenerate man pages (e.g. via help2man/makeinfo), groff-base is a smaller drop-in that covers most such needs. Worth confirming which a concrete formula actually requires; keep full groff if something genuinely depends on it.

Comment thread cmd/llard/Dockerfile
@@ -18,10 +18,15 @@ FROM debian:bookworm-slim

RUN apt-get update \
&& apt-get install -y --no-install-recommends \

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P3] Unpinned package versions affect build reproducibility

None of the apt packages are version-pinned (pre-existing pattern; these additions just follow it). Rebuilds are therefore non-reproducible and a toolchain upgrade could silently change how formulas build. Not a blocker for this PR — noting as a possible repo-wide follow-up (pin versions or document reliance on the bookworm snapshot).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant