SCA: Fix so-ver: depends losing their constraint, and allow packages to opt in

[xnox]

Melange Pull Request Template

Five commits, best reviewed one at a time:

1. pkg/build/package_test.go — a test showing bug fix: check for errors when computing the installed size #1 (this commit is intentionally red)
2. pkg/build/package.go — the fix for bug fix: check for errors when computing the installed size #1
3. config / sca / docs / schemas — a new versioned-shlib-deps option so a package can opt in
4. pkg/sca/sca.go — fix for bug build(deps): bump github.com/spf13/cobra from 1.3.0 to 1.4.0 #2, an inverted check that suppressed all cross-package
   versioned depends
5. .github/workflows/wolfi-presubmit.yaml — build jq with the feature on, to demonstrate it

Between them, commits 2 and 4 are what make the feature actually produce anything. Before this PR,
turning the feature on emitted either nothing at all or unconstrained depends.

Bug #1: the constraint was stripped

removeSelfProvidedDeps() strips the >=version from so-ver: dependencies so it can look the
dependency name up in the map of dependencies the package provides itself. It reassigns the loop
variable to do that, then appends the truncated value, so the constraint never reaches .PKGINFO:

in:  so:libc.so.6, so-ver:libc.so.6>=2.42-r0, so:libz.so.1, so-ver:libz.so.1>=1.3.1-r6
out: so:libc.so.6, so-ver:libc.so.6,          so:libz.so.1, so-ver:libz.so.1

An unversioned so-ver: depend is satisfied by any package providing the shared library, so the
generated dependency was a no-op. No existing test used so-ver: dependencies, so nothing caught
it. The fix uses a separate variable for the lookup key; the filtering behaviour is unchanged.

Bug #2: versioned depends were never emitted at all

determineShlibVersion() only emits a versioned depend if the providing package publishes a
matching versioned provides:, which it checks by parsing the provided version. The predicate
returned err != nil — so it accepted a provided version only when parsing failed, the
opposite of the comment directly above it:

_, err := apk.ParseVersion(providedVersion)
// If we're able to parse the version,
// then it's a valid one.
return err != nil       // ← accepts only unparseable versions

Every version in the wolfi index parses cleanly, so the check never matched and the function fell
through to returning an empty version. No versioned depend was generated for any library provided
by another package, even with the feature switched on — only libraries resolved via the
@CURRENT@ path could get one, since that returns earlier.

Commit 4 adds a test that runs determineShlibVersion() against a synthetic APKINDEX shaped like
the real one (oniguruma 6.9.10-r4 providing both so:libonig.so.5=5 and
so-ver:libonig.so.5=6.9.10-r4). It expects 6.9.10-r4 and fails without the fix; the companion
case, a provider with no versioned provides:, still correctly yields no versioned depend.

Demonstrating it in the wolfi presubmit

Commit 5 adds jq to the presubmit matrix and builds it with
MELANGE_VERSIONED_SHLIB_DEPENDS=1. jq links libonig, libc and libm, and all of the providing
packages publish versioned so-ver: provides in the index, so the build should turn today's

depend = so:ld-linux-x86-64.so.2
depend = so:libc.so.6
depend = so:libm.so.6
depend = so:libonig.so.5

into the same list plus so-ver:libc.so.6>=…, so-ver:libm.so.6>=… and
so-ver:libonig.so.5>=…, with ld-linux-x86-64.so.2 staying unversioned by design.

The variable is set for jq only; every other package builds exactly as before, since melange
reads an empty value as unset. The bubblewrap runner invokes melange through sudo, which resets
the environment, so there it is passed via env(1); the QEMU runner takes it from the step
environment directly. A new step prints the generated depends and fails the job if no so-ver:
depend was produced, so the demonstration cannot quietly become a no-op.

I tested that step's script both ways locally: it correctly fails against a real published
jq-1.7.1-r4.apk (built without the feature, no so-ver: depends) and passes against a
.PKGINFO carrying them. actionlint is clean.

The new option

Versioned shlib depends are gated behind the MELANGE_VERSIONED_SHLIB_DEPENDS environment
variable, which is per-build rather than per-package, and no-versioned-shlib-deps can only turn
them off — an individual package had no way to switch them on. So:

options:
  versioned-shlib-deps: true

It is a *bool, so unset / true / false are distinguishable. Precedence, in order: explicit
option, then the environment variable, then no-versioned-shlib-deps. true opts a package in
while the feature flag is still off; false opts one out while the flag is on; an explicit value
also wins over a stale no-versioned-shlib-deps: true in the same file rather than the two
silently cancelling out.

While documenting it I corrected two errors in the no-versioned-shlib-deps docs: versioned
depends are off by default, not on, and the option governs the shared libraries a package links
against, not the ones it ships — the versioned so-ver: provides are emitted regardless.

Functional Changes

• This change can build all of Wolfi without errors (describe results in notes)

Notes: not run. Both changes are inert unless versioned shlib depends are turned on:
determineShlibVersion() returns early otherwise, so no so-ver: depend is generated and
removeSelfProvidedDeps() has nothing new to preserve. MELANGE_VERSIONED_SHLIB_DEPENDS appears
in 0 files across stereo and enterprise-packages, and no package YAML there uses
no-versioned-shlib-deps, so nothing changes for those builds until someone opts in. The
so-ver: provides side is untouched by this PR.

Reviewers: if the flag is set anywhere I did not check, commit 2 makes those builds start
emitting real so-ver:...>= constraints where they previously emitted unconstrained ones. That is
the intended effect, but it is a genuine change in generated metadata and worth confirming against
an APKINDEX before enabling it broadly.

SCA Changes

• Examining several representative APKs show no regression / the desired effect (details in notes)

Notes: not done — verified at the unit level instead. Each commit was checked in a detached
worktree, since an uncommitted fix in the working tree would have made commit 1 look green:
commit 1 fails exactly as documented (so-ver:libc.so.6 vs so-ver:libc.so.6>=2.42-r0),
commit 2 turns pkg/build green, and the tip passes go build ./... plus all of ./pkg/...
and ./internal/....

New tests: TestVersionedShlibDepsEnabled covers the whole precedence matrix (7 cases);
Test_versionedShlibDepsOption round-trips the option's tri-state through
ParseConfiguration; Test_removeSelfProvidedDeps_KeepsSoVerConstraint guards the constraint.

The APK-level check now happens in CI: commit 5 builds jq with the feature on and asserts that
so-ver: depends appear in the built package, on both the bubblewrap and QEMU runners. That is
the real end-to-end signal for this PR — if the presubmit jq job goes green with so-ver: lines
in its output, the feature works on a real package; if the build fails resolving them, that is
worth knowing before anyone enables it more broadly.

Linter

• The new check is clean across Wolfi
• The new check is opt-in or a warning

Notes: N/A, no new linter check.

Note on the schemas

pkg/config/schema.json and schema.cue carry only the new versioned-shlib-deps block, copied
verbatim from go generate ./internal/gen-schema (verified byte-identical). Committing the full
regeneration would have added ~145 lines of unrelated churn: the checked-in schema.cue predates
cue v0.17's comment rewrapping, and schema.json is stale against current apko (format,
runtime_keyring, RuntimeKeyringEntry are missing). That drift is pre-existing and not enforced
by CI, and probably deserves its own regeneration commit.

Known limitation

Subpackages do not inherit the origin package's options — pkgFromSub() passes sub.Options
through verbatim and Options() returns a zero PackageOption{} when it is nil — so
versioned-shlib-deps has to be repeated on each subpackage that needs it. I left that alone
deliberately: making it inherit either changes inheritance for no-provides / no-depends /
no-commands too, or makes exactly one option inherit. If you want the narrow version, the
containable spot is SCABuildInterface.Options(), which can already see the origin's options.

🤖 Generated with Claude Code

[a-crate]

Mostly LGTM

with ld-linux-x86-64.so.2 staying unversioned by design

I'm not sure about this.

1. We generate so-ver provides for this today. 🔗 This contradicts this comment.
2. I think that comment is wrong, if we generate >= so-ver dependencies there's no reason we can't do the same for ld-linux that we're doing for libc. It's roughly the same blast radius.
3. Tests should assert this, and I think they will catch the bug from point 1.

[xnox]

Mostly LGTM

with ld-linux-x86-64.so.2 staying unversioned by design

I'm not sure about this.

1. We generate so-ver provides for this today. 🔗 This contradicts this comment.
2. I think that comment is wrong, if we generate >= so-ver dependencies there's no reason we can't do the same for ld-linux that we're doing for libc. It's roughly the same blast radius.
3. Tests should assert this, and I think they will catch the bug from point 1.

agree!