Make this a Keel package with a version we choose #8

New issue

Open

opened 2026-09-28 04:23:48 -03:00 by marcos-mendez · 0 comments

marcos-mendez commented

2026-09-28 04:23:48 -03:00

(Migrated from github.com)

Decision by the maintainer, 2026-09-28: stop patching TurnKey's fab and make
this a Keel package with a version we choose.

#7 is the symptom: the build host runs fab 1.1.1+keel2, a version that
exists in no commit of this repository, because two pull requests that changed
the order of the build's phases merged without a changelog entry and the
version was bumped at packaging time. A +keelN suffix on somebody else's
version string says we patched their thing; it is a half measure, and
1.1.1+keel2 is what that half measure produces.

This follows the pattern already set by keel-version and keel-sysinfo
(Keel-Linux/tracker#13) and by the command naming policy (handbook decision
0015): where the project depends on something, it owns it.

What has to be true

A Keel source package with our own version numbering, not one tracking
upstream's, built into our archive and signed like everything else.
Package relationships designed rather than guessed: Provides, Replaces
and Conflicts against fab, so the build host converts cleanly and can
never end up carrying both.
The command names almost certainly stay. fab-chroot,
fab-apply-overlay, FAB_PATH and $(FAB_PATH)/common appear throughout
buildtasks, in every recipe Makefile and in the bootstrap. Renaming the
binaries is a larger change than renaming the package and must not be
bundled into this one. The call sites decide it, so inventory them first.
The provenance question from #7 answered in the new shape: "which fab
built this layer" must be checkable from a manifest and a git tag, in both
directions. Owning the package makes that easier, not optional.
This repository calls the organization's require-changelog workflow. It
has only tests.yml today, which is the direct cause of #7.

The constraint that dominates

fab builds every layer. A broken fab stops the project.

The package and the migration plan are the deliverable; installing it on the
build host is a separate, scheduled step with the old package kept installable
and a written way back. Nothing here may leave the build host unable to build,
and no rebuild or reinstall happens as part of this issue.

Recorded where

Handbook decision note 0017, its own issue and pull request in that
repository. 0014, 0015 and 0016 are taken by work in flight, so the number is
fixed rather than "the next free one".

Decision by the maintainer, 2026-09-28: stop patching TurnKey's fab and make this a Keel package with a version we choose. `#7` is the symptom: the build host runs `fab 1.1.1+keel2`, a version that exists in no commit of this repository, because two pull requests that changed the order of the build's phases merged without a changelog entry and the version was bumped at packaging time. A `+keelN` suffix on somebody else's version string says we patched their thing; it is a half measure, and `1.1.1+keel2` is what that half measure produces. This follows the pattern already set by `keel-version` and `keel-sysinfo` (Keel-Linux/tracker#13) and by the command naming policy (handbook decision 0015): where the project depends on something, it owns it. ## What has to be true - A Keel source package with **our own version numbering**, not one tracking upstream's, built into our archive and signed like everything else. - Package relationships designed rather than guessed: `Provides`, `Replaces` and `Conflicts` against `fab`, so the build host converts cleanly and can never end up carrying both. - **The command names almost certainly stay.** `fab-chroot`, `fab-apply-overlay`, `FAB_PATH` and `$(FAB_PATH)/common` appear throughout `buildtasks`, in every recipe Makefile and in the bootstrap. Renaming the binaries is a larger change than renaming the package and must not be bundled into this one. The call sites decide it, so inventory them first. - The provenance question from `#7` answered in the new shape: "which fab built this layer" must be checkable from a manifest and a git tag, in both directions. Owning the package makes that easier, not optional. - This repository calls the organization's `require-changelog` workflow. It has only `tests.yml` today, which is the direct cause of `#7`. ## The constraint that dominates **fab builds every layer. A broken fab stops the project.** The package and the migration plan are the deliverable; installing it on the build host is a separate, scheduled step with the old package kept installable and a written way back. Nothing here may leave the build host unable to build, and no rebuild or reinstall happens as part of this issue. ## Recorded where Handbook decision note **0017**, its own issue and pull request in that repository. 0014, 0015 and 0016 are taken by work in flight, so the number is fixed rather than "the next free one".