commit 4d4b9a976ca7e2fd3fb8308430f68a0fd4256802
Author: lucascouts <lucascs@protonmail.com>
Date: Tue Sep 8 22:42:23 2026 -0300

add(dev-util/opencodex-2.48.0), add(metadata/md5-cache/dev-util/opencodex-2.48.0), mod(.autoupdate/packages.toml, profiles/use.local.desc): package lidge-jun/opencodex on the system Bun

opencodex is a universal provider proxy: it speaks the OpenAI Responses and
Anthropic Messages APIs on the front and forwards to whatever is configured
behind it, so Codex CLI/App/SDK and Claude Code can be pointed at Claude,
Gemini, Grok, DeepSeek, OpenRouter or a local Ollama. MIT, TypeScript, and no
compile step at all -- src/ is executed directly by Bun.

The launcher choice is the whole design. Upstream ships bin/ocx.mjs, a Node
shim that locates a bundled Bun and spawns it; this package instead execs
net-libs/bun-bin straight at src/cli/index.ts. That buys two things at once.
net-libs/nodejs leaves the dependency graph entirely, and `ocx update` starts
classifying the install as a source layout, at which point it REFUSES to write
an npm tree into /usr. The refusal is upstream behaviour, not a patch -- only
the ADVICE it prints is rewritten, to name Portage instead of a git checkout
the user does not have. Both seds are guarded with grep -qF, so they die
loudly if upstream rewords the line rather than silently becoming no-ops.

SRC_URI takes the npm tarball and not the GitHub tag, because only the npm one
carries gui/dist, the Vite-built web UI. The tag would force a networked
`bun install` plus a Vite build inside the gui/ workspace.

The 93-package runtime dependency tree is vendored as a second distfile on
distfiles.obentoo.org, generated from upstream's own bun.lock with
--frozen-lockfile so it is reproducible from the tag rather than from the day
it ran. Ninety-three tgz in SRC_URI was not an option; the precedent is
sci-ml/lemonade's webapp bundle. @oven/bun-* -- ~149 MiB of interpreter -- is
dropped on purpose: the runtime comes from net-libs/bun-bin, not from a second
unmanaged copy buried in /usr/lib.

USE=keyring (default on) covers the only native code in the package.
@napi-rs/keyring ships per-platform prebuilts, so the blob is a third distfile
gated per arch, and both linux-x64-gnu and linux-arm64-gnu exist upstream --
which is what makes ~arm64 possible here at all. With -keyring the image
contains zero prebuilt binaries and keys stay in opencodex's own config, which
is a working configuration and not an invalid one, so there is no REQUIRED_USE.
The blob links only glibc and libgcc and speaks org.freedesktop.secrets over an
embedded D-Bus client, so the Secret Service provider it needs is a runtime
expectation stated in pkg_postinst, not a dependency that can be declared.

The user-scope OpenRC script has no system-scope counterpart on purpose:
opencodex holds per-user provider credentials under ~/.opencodex and binds
loopback only, so a system instance would either serve one user's keys to every
account on the box or have no keys at all. `ocx service install` writes a user
systemd unit at runtime, so this ebuild installs no unit and the coverage rule
is not triggered by an installed file -- but someone without systemd still has
no supervised way to run the proxy, which is the situation that rule exists to
prevent.

The autoupdate record is held, and not provisionally. SRC_URI carries
distfiles no upstream produces, so an applied bump would move PV past a tarball
that does not exist yet and leave the ebuild unfetchable. Every bump is two
steps: regenerate and upload the vendor tarball first, then release the hold.
The probe is npm dist-tags.latest rather than a tag ranking, because upstream
cuts a preview alongside nearly every release -- 2.48.0 and
2.48.0-preview.20260908 landed 18 minutes apart -- and ranking tags would elect
the preview into a permanent false "outdated".

Verified locally, without root, via PORTAGE_CONFIGROOT with FEATURES=unprivileged:
- two full installs (USE=keyring and USE=-keyring), both exit 0
- all four distfiles fetched and checked against the Manifest
- the installed image runs: `ocx status` exits 0 and reports the Bun runtime
- `ocx update` prints the Portage advice; both seds landed in the image
- the USE=-keyring image contains zero .node/.so files
- node_modules/.bin/node-which survives as a relative symlink (cp -a, not doins)
- pkgcheck, check-openrc-coverage.sh, shellcheck, bash -n, metadata DTD: clean
- md5-cache _md5_ matches md5sum of the ebuild on disk
- the three obentoo distfiles re-fetched from the CDN and hash-compared after upload

Nothing was merged for real -- this host has no sudo. ~arm64 is analytic, not
tested: the blob is a valid aarch64 ELF and net-libs/bun-bin carries ~arm64,
but nothing was executed on that architecture.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>