Decision note 0017: owning fab, and how a package this project depends on is named #17

New issue

Open

opened 2026-09-28 05:48:20 -03:00 by marcos-mendez · 0 comments

marcos-mendez commented

2026-09-28 05:48:20 -03:00

(Migrated from github.com)

Decision note 0017, and only 0017: 0014, 0015 and 0016 are concurrent
work, so the number is fixed here rather than taken as "the next free one" at
write time.

The maintainer decided on 2026-09-28, in Keel-Linux/fab#8, to stop patching
TurnKey's fab and make it a Keel package with a version this project chooses.
The implementation is Keel-Linux/fab#9. The reasoning belongs in a note
because it settles a rule that outlives fab.

What the note has to state

The rule. A Debian package this project depends on and modifies becomes
a Keel package with a version this project chooses, rather than upstream's
version with a +keelN suffix. For fab: source and binary package
keel-fab at 0.1.0.
That the package name and the repository name are different axes.
Decision 0006 rules that infrastructure keeps its upstream name with no
prefix, and names fab explicitly. That rule is about repositories and it
stands; this is the first time the two diverge and the note has to say so,
or 0006 and the new rule read as contradicting each other.
Where the version scheme boundary is. Brief section 7's +keelN is for
a rebuild of an upstream package. apt/lib/build.sh already implements the
boundary and keys it on the keel prefix of Source, so a package that
crosses one crosses both.
The Provides/Replaces/Conflicts triple, with the reason for each
field. This is the first one in this organization's packaging and
tracker#13 needs it next, for packages whose Provides will be doing real
work that fab's is not. Recorded reasoning, not three copied fields.
Why the command names do not change, from the call site inventory
rather than from a preference, and why decision 0015 does not reach them:
fab-chroot and its siblings are not operator facing.
The provenance answer in the new shape. "Which fab built this layer"
checkable from a manifest and a git tag, in both directions, and what that
requires.
How the build host is converted and how to go back. fab builds every
layer, so the note is where the operator looks. Nothing may leave the build
host unable to build, and the conversion is scheduled deliberately rather
than done as part of this work.

What belongs in the note rather than in a commit message

The three part justification of brief section 10: why the +keelN
arrangement does not hold, whether it could be made to, and why owning the
package is better. And what the note does not decide, which is at least: when
the conversion happens, whether the binaries are ever renamed, and what
happens to the other packages the project rebuilds.

Not in scope

docs/build-host.md sections 2 and 3 describe the fab package, its pin and
its .deb and will need the new name, but at conversion time and not before:
until then they describe what is actually installed. Same for the pin defect
in Keel-Linux/apt#15, which is live and independent of this note.

Decision note **0017**, and only 0017: 0014, 0015 and 0016 are concurrent work, so the number is fixed here rather than taken as "the next free one" at write time. The maintainer decided on 2026-09-28, in Keel-Linux/fab#8, to stop patching TurnKey's fab and make it a Keel package with a version this project chooses. The implementation is Keel-Linux/fab#9. The reasoning belongs in a note because it settles a rule that outlives fab. ## What the note has to state - **The rule.** A Debian package this project depends on and modifies becomes a Keel package with a version this project chooses, rather than upstream's version with a `+keelN` suffix. For fab: source and binary package `keel-fab` at `0.1.0`. - **That the package name and the repository name are different axes.** Decision 0006 rules that infrastructure keeps its upstream name with no prefix, and names `fab` explicitly. That rule is about repositories and it stands; this is the first time the two diverge and the note has to say so, or 0006 and the new rule read as contradicting each other. - **Where the version scheme boundary is.** Brief section 7's `+keelN` is for a rebuild of an upstream package. `apt/lib/build.sh` already implements the boundary and keys it on the `keel` prefix of `Source`, so a package that crosses one crosses both. - **The `Provides`/`Replaces`/`Conflicts` triple, with the reason for each field.** This is the first one in this organization's packaging and tracker#13 needs it next, for packages whose `Provides` will be doing real work that fab's is not. Recorded reasoning, not three copied fields. - **Why the command names do not change**, from the call site inventory rather than from a preference, and why decision 0015 does not reach them: `fab-chroot` and its siblings are not operator facing. - **The provenance answer in the new shape.** "Which fab built this layer" checkable from a manifest and a git tag, in both directions, and what that requires. - **How the build host is converted and how to go back.** fab builds every layer, so the note is where the operator looks. Nothing may leave the build host unable to build, and the conversion is scheduled deliberately rather than done as part of this work. ## What belongs in the note rather than in a commit message The three part justification of brief section 10: why the `+keelN` arrangement does not hold, whether it could be made to, and why owning the package is better. And what the note does not decide, which is at least: when the conversion happens, whether the binaries are ever renamed, and what happens to the other packages the project rebuilds. ## Not in scope `docs/build-host.md` sections 2 and 3 describe the fab package, its pin and its `.deb` and will need the new name, but at conversion time and not before: until then they describe what is actually installed. Same for the pin defect in Keel-Linux/apt#15, which is live and independent of this note.