Build keel-version and keel-sysinfo as Keel packages #13

New issue

Open

opened 2026-09-27 23:19:58 -03:00 by marcos-mendez · 0 comments

marcos-mendez commented

2026-09-27 23:19:58 -03:00

(Migrated from github.com)

This supersedes the open question in #12 about what to do with the turnkey-*
commands a Debian package owns.

Measured on the `wordpress-demo` container, 2026-09-28

Package	Version	Maintainer	Ships
`turnkey-version`	1.1.3	TurnKey	`/usr/bin/turnkey-version`, python module `sysversion`
`turnkey-sysinfo`	1.1.0	TurnKey	`/usr/bin/turnkey-sysinfo`, `/usr/bin/turnkey-detect-virt`, python module `libsysinfo` (`disk`, `memstats`, `virt`), `/usr/share/turnkey-sysinfo/contrib/motd`

Reverse dependencies, on a real appliance:

turnkey-version — exactly one, turnkey-sysinfo.
turnkey-sysinfo — none.

The pair is a closed set. Replacing both breaks no other package in the
archive, which is what makes this doable now rather than later. Note
turnkey-detect-virt, a third command in the family that #12's table missed.

What has to be true

keel-version and keel-sysinfo, built from Keel source packages in the
Keel-Linux organization, published to our own archive, signed like everything
else.
The real commands are keel-version and keel-sysinfo; the turnkey-*
names keep working, per the policy in decision 0015.
The python import names in use today (sysversion, libsysinfo) must keep
importing. Decide whether the Keel package ships those module names directly
or ships Keel-named modules with compatibility shims, and say why.
Package relationships have to be worked out and stated: Provides,
Replaces, Conflicts against the TurnKey names, so that an upgrade of an
existing appliance converts cleanly and a fresh build never installs both.
An upgrade path that leaves both installed, or that loses a file to the other
package's ownership, is the failure to design against.
keel-version reads /etc/keel_version first and falls back to
/etc/turnkey_version, per decision 0014. It must not print
"TurnKey GNU/Linux".
keel-sysinfo keeps every system fact the TurnKey one reports — load, memory,
processes, swap, usage of /, addresses per interface — and says nothing about
TKLBAM or the Hub. What it says about backup instead is decided in 0014.

Coordination, which matters more than the code here

Two changes are in flight that touch the same surface:

#6 is fixing the motd chain now, with the TurnKey packages still installed,
and is writing decision 0014.
#12 is renaming the commands this project's own overlays write, and is
writing decision 0015.

This work must reuse what those two produce, not write a second copy of it.
In particular: if #6 puts sysinfo logic into a keel-core overlay library, this
work moves that logic into the keel-sysinfo package and the overlay stops
carrying it. Two implementations of the same banner is exactly the duplication
this project keeps paying for. Start by reading what #6 and #12 actually
landed.

Order

Land the packages and publish them to the archive first; the layer chain
rebuild that puts them on an appliance is a separate, deliberate step, because
keel-core is the parent of all eleven layers.

Decision by the maintainer, 2026-09-28: Keel builds and owns these two packages itself, rather than wrapping or diverting TurnKey's. A distribution cannot claim to be sovereign while the commands that state its identity come out of somebody else's archive. This supersedes the open question in #12 about what to do with the `turnkey-*` commands a Debian package owns. ## Measured on the `wordpress-demo` container, 2026-09-28 | Package | Version | Maintainer | Ships | |---|---|---|---| | `turnkey-version` | 1.1.3 | TurnKey | `/usr/bin/turnkey-version`, python module `sysversion` | | `turnkey-sysinfo` | 1.1.0 | TurnKey | `/usr/bin/turnkey-sysinfo`, `/usr/bin/turnkey-detect-virt`, python module `libsysinfo` (`disk`, `memstats`, `virt`), `/usr/share/turnkey-sysinfo/contrib/motd` | Reverse dependencies, on a real appliance: - `turnkey-version` — exactly one, `turnkey-sysinfo`. - `turnkey-sysinfo` — **none**. The pair is a closed set. Replacing both breaks no other package in the archive, which is what makes this doable now rather than later. Note `turnkey-detect-virt`, a third command in the family that #12's table missed. ## What has to be true - `keel-version` and `keel-sysinfo`, built from Keel source packages in the Keel-Linux organization, published to our own archive, signed like everything else. - The real commands are `keel-version` and `keel-sysinfo`; the `turnkey-*` names keep working, per the policy in decision 0015. - The python import names in use today (`sysversion`, `libsysinfo`) must keep importing. Decide whether the Keel package ships those module names directly or ships Keel-named modules with compatibility shims, and say why. - Package relationships have to be worked out and stated: `Provides`, `Replaces`, `Conflicts` against the TurnKey names, so that an upgrade of an existing appliance converts cleanly and a fresh build never installs both. An upgrade path that leaves both installed, or that loses a file to the other package's ownership, is the failure to design against. - `keel-version` reads `/etc/keel_version` first and falls back to `/etc/turnkey_version`, per decision 0014. It must not print "TurnKey GNU/Linux". - `keel-sysinfo` keeps every system fact the TurnKey one reports — load, memory, processes, swap, usage of /, addresses per interface — and says nothing about TKLBAM or the Hub. What it says about backup instead is decided in 0014. ## Coordination, which matters more than the code here Two changes are in flight that touch the same surface: - #6 is fixing the motd chain now, with the TurnKey packages still installed, and is writing decision 0014. - #12 is renaming the commands this project's own overlays write, and is writing decision 0015. This work must **reuse** what those two produce, not write a second copy of it. In particular: if #6 puts sysinfo logic into a keel-core overlay library, this work moves that logic into the `keel-sysinfo` package and the overlay stops carrying it. Two implementations of the same banner is exactly the duplication this project keeps paying for. Start by reading what #6 and #12 actually landed. ## Order Land the packages and publish them to the archive first; the layer chain rebuild that puts them on an appliance is a separate, deliberate step, because keel-core is the parent of all eleven layers.