Operator facing commands still carry the TurnKey name #12

New issue

Closed

opened 2026-09-27 23:15:52 -03:00 by marcos-mendez · 1 comment

marcos-mendez commented

2026-09-27 23:15:52 -03:00

(Migrated from github.com)

The commands an operator types every day still carry another distribution's
name, and several of them are written by Keel's own overlays rather than
inherited from a package.

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

Command	Where it comes from
`/usr/local/bin/turnkey-wp`	keel-wordpress `overlay/usr/local/bin/turnkey-wp` — ours
`/usr/local/sbin/turnkey-wordpress-update`	keel-wordpress overlay — ours
`/usr/local/bin/turnkey-php`	inherited, build time
`/usr/local/bin/turnkey-mysql-install-perf-info-schemas`	inherited, build time
`turnkey-sysinfo`, `turnkey-version`	Debian packages `turnkey-sysinfo`, `turnkey-version`

Two of those are files this project writes and names itself, which makes this
our defect and not an inherited one.

The decision, taken by the maintainer on 2026-09-28

The Keel name becomes the real command and the turnkey-* name is kept as a
symlink to it. Both keep working; the appliance speaks its own name.

Scope is a general policy, not a per-appliance choice, recorded as decision
note 0015 in the handbook. The reason for the symlink is the same reason
/etc/turnkey_version keeps its name in 0014: compatibility with TurnKey is a
stated property of this project, and an operator who pasted a command out of
TurnKey's documentation, or who wrote a script against turnkey-wp last year,
must not silently lose it.

What closes this

A policy in docs/decisions/0015-* stating the rule, what it applies to, and
what happens to a turnkey-* name a package owns (turnkey-sysinfo and
turnkey-version are dpkg-owned; a symlink cannot simply replace them, and
the note must say what is done instead).
keel-wp as the real command in keel-wordpress, with turnkey-wp a symlink,
and the same for keel-wordpress-update.
The tests exercise the Keel name, and one test asserts the compatibility
symlink resolves and works. Today tests/v19.sh drives turnkey-wp through
siteurl, post create/get/delete, core version, check-update and
verify-checksums; that coverage must not shrink.
Nothing in the wrapper's behaviour changes: it still runs as www-data with
an explicit --path, never as root.

Order

The commands owned by Keel's own overlays come first, because they need no core
rebuild. The package-owned ones (turnkey-sysinfo, turnkey-version) touch
keel-core and therefore the whole layer chain, so they wait for a deliberate
rebuild.

The commands an operator types every day still carry another distribution's name, and several of them are written by Keel's own overlays rather than inherited from a package. Measured on the `wordpress-demo` container, 2026-09-28: | Command | Where it comes from | |---|---| | `/usr/local/bin/turnkey-wp` | keel-wordpress `overlay/usr/local/bin/turnkey-wp` — ours | | `/usr/local/sbin/turnkey-wordpress-update` | keel-wordpress overlay — ours | | `/usr/local/bin/turnkey-php` | inherited, build time | | `/usr/local/bin/turnkey-mysql-install-perf-info-schemas` | inherited, build time | | `turnkey-sysinfo`, `turnkey-version` | Debian packages `turnkey-sysinfo`, `turnkey-version` | Two of those are files this project writes and names itself, which makes this our defect and not an inherited one. ## The decision, taken by the maintainer on 2026-09-28 The Keel name becomes the real command and the `turnkey-*` name is kept as a symlink to it. Both keep working; the appliance speaks its own name. Scope is a **general policy**, not a per-appliance choice, recorded as decision note 0015 in the handbook. The reason for the symlink is the same reason `/etc/turnkey_version` keeps its name in 0014: compatibility with TurnKey is a stated property of this project, and an operator who pasted a command out of TurnKey's documentation, or who wrote a script against `turnkey-wp` last year, must not silently lose it. ## What closes this - A policy in `docs/decisions/0015-*` stating the rule, what it applies to, and what happens to a `turnkey-*` name a package owns (`turnkey-sysinfo` and `turnkey-version` are dpkg-owned; a symlink cannot simply replace them, and the note must say what is done instead). - `keel-wp` as the real command in keel-wordpress, with `turnkey-wp` a symlink, and the same for `keel-wordpress-update`. - The tests exercise the **Keel** name, and one test asserts the compatibility symlink resolves and works. Today `tests/v19.sh` drives `turnkey-wp` through siteurl, post create/get/delete, `core version`, `check-update` and `verify-checksums`; that coverage must not shrink. - Nothing in the wrapper's behaviour changes: it still runs as `www-data` with an explicit `--path`, never as root. ## Order The commands owned by Keel's own overlays come first, because they need no core rebuild. The package-owned ones (`turnkey-sysinfo`, `turnkey-version`) touch keel-core and therefore the whole layer chain, so they wait for a deliberate rebuild.

marcos-mendez commented

2026-09-29 17:38:11 -03:00

(Migrated from github.com)

Every item under "What closes this" is in: decision 0015 (handbook#3); keel-wp and keel-wordpress-update are the real commands in keel-wordpress, with turnkey-wp and turnkey-wordpress-update as symlinks; tests/v19.sh and tests/wrappers.bats drive the Keel names. What remains of the table lives elsewhere: turnkey-version, turnkey-sysinfo and turnkey-detect-virt in #13; turnkey-php and turnkey-mysql-install-perf-info-schemas, which come in at build time, in #15.

Every item under "What closes this" is in: decision 0015 (handbook#3); `keel-wp` and `keel-wordpress-update` are the real commands in keel-wordpress, with `turnkey-wp` and `turnkey-wordpress-update` as symlinks; `tests/v19.sh` and `tests/wrappers.bats` drive the Keel names. What remains of the table lives elsewhere: `turnkey-version`, `turnkey-sysinfo` and `turnkey-detect-virt` in #13; `turnkey-php` and `turnkey-mysql-install-perf-info-schemas`, which come in at build time, in #15.