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

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.