Keel-Linux/tracker

Fork 0

Where each TurnKey-archive package should go: Debian, our archive, or nowhere #15

New issue

Open

opened 2026-09-28 00:15:11 -03:00 by marcos-mendez · 0 comments

marcos-mendez commented

2026-09-28 00:15:11 -03:00

(Migrated from github.com)

Every Keel appliance built today still resolves packages from
archive.turnkeylinux.org, over plain HTTP, verified with a key that is not
ours. This note enumerates what actually comes from there, and says for each
one whether it should go to Debian, into our archive, or nowhere.

The short answer to the question as asked: almost nothing here should
become a new Debian source package. One item is worth sending to Debian
now, and it should go as a patch to a package Debian already has, not as a
new one. That route costs no ITP, no sponsor and no NEW queue.

Ground truth

Measured 2026-09-28 on four containers on the build host (wordpress-demo,
forum, forum2, tkl-core-bench), cross-checked against
common/plans/turnkey/base, which is where these packages actually enter a
build. Nothing was modified; no build was started.

The appliance carries two enabled sources it does not own:

/etc/apt/sources.list.d/sources.sources
/etc/apt/sources.list.d/security.sources.sources
  URIs: http://archive.turnkeylinux.org/debian
  Signed-By: /usr/share/keyrings/tkl-archive-keyring.gpg

Both are plain HTTP, and the keyring comes from turnkey-keys, a package
from that same archive. A third, turnkey-testing.sources, is present and
disabled. Decision 0012 already records the consequence: that archive keeps
no snapshots, so a version we pin today is unfetchable within weeks, and the
rebuild promise cannot be kept while any part of the image comes from there.

dpkg-vendor --query Vendor on a Keel appliance still answers TurnKey, and
apt announces itself to every archive it contacts as
TurnKey APT-HTTP/1.3 (turnkey-wordpress-19.0-trixie-amd64).

The shortlist, and how many is realistic

One, going to Debian as a patch rather than a package. Possibly a second.
Zero new Debian source packages this cycle.

Proposing a package to Debian is a standing maintenance obligation, and this
project has one maintainer who is not a Debian Developer. The honest capacity
is one contribution that lands and stays landed, not a portfolio.

tkl-dhcpcd-ifupdown-glue — 119 lines of clean bash, GPL-3+, written
2026, with exactly one TurnKey string in it (a comment). Its if-pre-up
and if-post-down hooks write and remove noipv4 / noipv6 deny stanzas
in dhcpcd.conf so that dhcpcd, running as a system daemon, stops
claiming interfaces that /etc/network/interfaces declares static.

Be precise about the gap, because it is narrower than it first looks.
ifupdown 0.8.44 already knows about dhcpcd: its inet dhcp method falls
back dhclient → udhcpc → dhcpcd. ifupdown-ng 0.12.1 probes
/sbin/dhcpcd first in determine_implementation(). So "ifupdown
cannot drive dhcpcd" is false. What is true is that dhcpcd-base in
trixie ships zero files under /etc/network (verified against its file
list: only /etc/dhcpcd.conf, /usr/lib/dhcpcd/dhcpcd-hooks/* and
/usr/share/dhcpcd/hooks/*), so when dhcpcd runs as a daemon in parallel
with ifupdown, nothing tells it to keep its hands off the static
interfaces. That is the actual gap and that is what these 119 lines fill.

Too small to justify its own source package. The right destination is a
wishlist bug with a patch against Debian's dhcpcd. No ITP, no sponsor,
no NEW queue, and if it is accepted we delete a package instead of gaining
one.
The SAN and wildcard handling in turnkey-make-ssl-cert (from
turnkey-ssl) — Debian's ssl-cert 1.1.3 ships make-ssl-cert, which
generates snakeoil self-signed certs and nothing more. The delta (subject
alternative names, wildcards, IP SANs, CSR output) is a genuine gap and is
offerable as a wishlist bug with a patch against ssl-cert. Second
cheapest thing on this list. The rest of turnkey-ssl must not be offered
to anybody, for the reason in the defects section below.

Everything else is either ours to keep, or ours to delete.

Worth stating plainly, because it bears on all of this: none of these
thirteen TurnKey-named packages exists in Debian, and not one of them has
ever had a wnpp bug — no ITP, no RFP, open or archived. Nobody has ever
asked Debian for any of them. That is not an opening; it is a signal about
demand.

Full verdict table

LOC counts code, not tests or packaging.

TurnKey-authored, from TurnKey's archive

Package	What it does (from the code)	LOC	Licence	Verdict	Reason
`tkl-dhcpcd-ifupdown-glue` 0.1.3	ifupdown pre-up/post-down hooks that add or remove `noipv4`/`noipv6` stanzas in `dhcpcd.conf` so dhcpcd leaves statically configured interfaces alone	119 sh	GPL-3+	Debian	Generic, tiny, clean; goes as a patch to Debian's `dhcpcd`, not a new package
`turnkey-ssl` 3.1.1	`turnkey-make-ssl-cert`: an openssl wrapper that builds self-signed certs with SANs and wildcards, and concatenates cert+key+dhparams into one PEM	414 sh	GPL-3+	Keel (SAN delta to Debian as a patch)	Ships a private key in the .deb; see defects
`confconsole` 2.2.3	The tty1 TUI: usage screen with addresses and service URLs, plus plugins for networking, region, proxy, mail relay, security updates and Let's Encrypt	4,650 py + 753 sh	GPL-3+, three files AGPL-3+	Keel	Already diverged; and it is not packageable as-is, see below
`inithooks` 2.3.6	systemd unit on tty1 that runs `firstboot.d/` once and `everyboot.d/` each boot, sourcing `/etc/inithooks.conf`, with dialog and preseed modes	2,449 py + 1,621 sh	GPL-2+	Keel	The idea is generic; this implementation is not, and Debian's answer is `cloud-init`
`tkl-installer` 0.1.2	Minimal CLI installer for Debian live systems: disk detection, partitioning, formatting, rootfs copy, grub. Replaces d-i on the ISO	4,461 py	GPL-3+	Keel, or drop	Debian already has `debian-installer-launcher` 44 and `calamares` 3.3.14, so this is not a gap. New in 2026, unproven, partitions disks as root
`turnkey-netinfo` 1.1.1	Interface and address enumeration via raw `ioctl` (`SIOCGIFADDR` and friends)	232 py	GPL-3+	Drop	IPv4-era ioctl wrapper; `python3-psutil` and `python3-pyroute2` are in Debian and do it properly. For the banner case, `agetty` already expands `\4` and `\6` in `/etc/issue`
`turnkey-conffile` 1.1.2	A `dict` subclass that reads and writes `KEY=value` shell-style config files with attribute access	97 py	GPL-3+	Drop	97 lines; fold into the `keel` library or use `python3-dotenv`
`py3curl-wrapper` 2.1.2	A requests-shaped API over pycurl	259 py	GPL-2+	Drop	`python3-requests` exists; and this one reads `/etc/apt/apt.conf.d/01turnkey` to put the appliance build ID in its User-Agent
`hubdns` 1.4.0	Dynamic DNS client that registers the appliance against the TurnKey Hub API, on an hourly cron	294 py	GPL-3+	Drop	Hub-specific by definition; decision 0002 defers the Hub. `ddclient` and `inadyn` are in Debian
`tklbam` 1.5.3	Backup and migration: diffs the filesystem against pristine dpkg state, dumps MySQL/PostgreSQL, drives duplicity, and talks to the Hub	10,234 py + 7.2 MB vendored	GPL-3+	Drop as packaged	See defects. Decision 0002 defers it; the idea inside it is worth keeping as new code
`tklbam-squid` / `-common`	Squid 2.7.STABLE9, vendored into `/usr/lib/tklbam/deps/usr/sbin/squid` as tklbam's package-download cache	(2010 upstream)	GPL-2	Drop, first	A 16-year-old unpatched proxy on every appliance. Debian trixie has Squid 6.13; no squid 2.x exists anywhere in Debian
`turnkey-pypy2` 7.3.23	A 41 MB PyPy 2.7 interpreter, installed solely so tklbam can run Python 2 code	41 MB binary	MIT (PyPy)	Drop with tklbam	PyPy 2 is not in Debian at all, and `python2.7` is gone from trixie. We are carrying a Python 2 runtime Debian deliberately removed
`turnkey-keys` 0.1	TurnKey's APT and image signing keyrings, buster through trixie	keys only	unstated	Drop	`keel-archive-keyring` already replaces it
`turnkey-version` 1.1.3	`/usr/bin/turnkey-version`, python module `sysversion`	—	GPL-3+	Keel	Already decided, #13
`turnkey-sysinfo` 1.1.0	`turnkey-sysinfo`, `turnkey-detect-virt`, module `libsysinfo`	—	GPL-3+	Keel	Already decided, #13
`turnkey-core-19.0`, `turnkey-<app>-19.0`	Empty release-marker metapackages	0	unstated	Keel	Rename to `keel-*`; some are already built by us

Repackaged, not TurnKey's to give and not ours

Package	What it is	Verdict	Reason
`webmin` + 25 `webmin-*` modules	Upstream Webmin, re-split by TurnKey from the `webmin-minimal` and full tarballs into a core package plus one package per module. 150 MB of source. Unmodified upstream code plus packaging	Keel if we keep it, but decide whether to keep it	Not ours to upstream, and Debian's absence of Webmin is a deliberate position, not a gap waiting to be filled
`webmin-tklbam` 1.2.1	A single `tklbam.wbm.gz` Webmin module for tklbam	Drop	Follows tklbam

The Webmin question deserves its own decision note rather than a line in a
table, and the reason Debian does not have Webmin is the most useful thing I
found while measuring.

Webmin is not missing from Debian. It was thrown out, by its own
maintainer, and three attempts to bring it back have failed over twenty
years. Note that the widely repeated "Debian dropped Webmin for security
reasons" story is not what the record says, and we should not repeat it.
There is no DFSG or licence ruling against Webmin anywhere.

Packaged from 2000 (#75030 ITP) by
Jaldhar H. Vyas. Shipped through sarge.
#271505 (Sep 2004) RFA: webmin. No
taker for fifteen months.
#343897, 2005-12-18, "ftp.debian.org:
Please remove all webmin related packages", filed by Vyas himself and
executed by Joerg Jaspert on 2006-01-12. Sarge had carried 65 webmin*
binary packages on i386 alone. The machine-readable reason in the archive
removal log is RoM; outdated; unmaintained — note, not security.
Vyas's own words: "less and less time and motivation to keep at it";
"I have always been more or less the only person looking after them";
"It is better to drop them now rather than perpetrate the cruel joke
that these are Debian-quality packages"; and "we owe it to Jamie
Cameron, the author of webmin, not to besmirch his name and product with
buggy crap." Asked why he would not simply orphan them, he said orphaning
had produced "an initial flurry of interest that rarely panned out". The
removal was copied to debian-devel and drew no replies at all.
#377948 (Jul 2006) ITP: webmin.
Upstream author Jamie Cameron took part personally. It stalled on
packaging basics (a DEBIAN/ directory instead of debian/, so
dpkg-buildpackage would not run; /etc/webmin generated at install time
rather than shipped). Closed 2010-01-09 by Steffen Joeris of the
security team: "There hasn't been any progress on this ITP for quite a
long time and webmin continues to receive CVE ids, which we (security
team) need to track in our tracker because of this ITP."
#820659, filed 2016, is still open
today as an RFP. It briefly became an ITP and was reverted to RFP in
February 2024 when the prospective maintainer gave up. His parting
assessment is the most useful sentence in the whole file: "webmin is the
most awkward and terrible project I've ever seen, which contains tons of
outdated sources and countless fixed paths."
That same attempt produced the vendored-code evidence, in RFS
#880590. Emmanuel Bourg, 2018-01-16:
"I think getting rid of the prebuilt binaries will be required to upload
it. The flashterm, ftelnet and shellinabox directories could probably be
removed from the upstream tarball […] out of the embedded .jar files it
seems only jta26.jar is actually used […] (however I question the
relevance of embedding a Java applet in 2018 now that this technology has
been removed from all major browsers)." The request was duly retitled
webmin/1.870-1 → webmin/1.870+ds-1: a repack was mandatory. Andrey
Rahmatullin, 2017-11-06: "The package has lots of lintian-detected
problems, some of them critical." The RFS timed out and was closed in
October 2018. That attempt would have produced roughly 150 binary
packages.
Upstream's own answer, Jamie Cameron, asked in July 2025 why cockpit is
in Debian and Webmin is not: "Honestly we never really looked into it, and
found it easier to just create our own repository that we can push updates
to via our own release processes."
The security load, for scale: Debian's security tracker carries 96 CVE
entries mentioning Webmin, 86 of them marked <removed>, of which seven
were assigned in 2026 alone. While it was in the archive it cost five
DSAs.
usermin and virtualmin are not in Debian either and have no current
wnpp bug. Virtualmin only ever existed as webmin-virtual-server, removed
with the rest in January 2006.
cockpit is in Debian: 337-1+deb13u2 in trixie, with security updates,
368-1 in forky/sid.

Read that against our situation. The reasons Webmin is not in Debian are: one
maintainer could not sustain it, the tree is large and carries prebuilt
binaries and hardcoded paths, and it accumulates CVEs faster than a volunteer
can track them. We have one maintainer. We ship 26 Webmin packages in the
base layer of every appliance, rebuilt by a third party whose archive keeps
no snapshots (decision 0012). Every reason Debian has for not carrying Webmin
applies to us, with fewer people.

To be scrupulous about what is and is not sourced here: I could find no
Debian developer on record saying Webmin was rejected for fighting the
distribution's configuration management, and no licence or DFSG objection to
Webmin itself (it is BSD; the 2018 repack demand was about prebuilt binaries,
which is source cleanliness, not licensing). The sourced objections are
sole-maintainer burnout, staleness, prebuilt binaries, hardcoded paths and
CVE volume. That is enough on its own; we do not need the stronger claim and
should not make it.

On cockpit as the alternative, honestly. It is in Debian (trixie
337-1+deb13u2 with security updates, 368-1 in forky), maintained by the
Utopia Maintenance Team, and split into nine binary packages. It is
architecturally the thing Debian wanted: it drives existing system D-Bus APIs
instead of parsing and rewriting each service's config files, authenticates
real system users through PAM instead of keeping its own password store, and
is fine-grained rather than monolithic. But it is not a feature superset,
and anyone proposing a swap has to own that: Debian has no cockpit module for
BIND, Postfix, Exim, Samba, Squid, ProFTPD, DHCP or Apache, all of which
Webmin covers and several of which our appliances are built around.

I am therefore not recommending a Webmin verdict here, because it is a
product decision and not a packaging one: for a lot of appliance users the
Webmin panel is the product. I am recommending that the decision be made,
deliberately, written down, and costed against that gap list rather than
against a slogan.

Fourth category: TurnKey-authored files in no package at all

Written into the image at build time by common/conf/turnkey.d/* and
common/overlays/turnkey.d/*, owned by no package, therefore not
upgradeable, not verifiable and not removable:

File	Lines	What it is
`/usr/local/bin/apt-packages-origin`	84 py	Parses `apt-cache policy` to report which archive each package came from
`/usr/local/bin/gh_releases`	124 sh	Queries the GitHub releases API
`/usr/local/bin/turnkey-php`	54 sh	PHP version switcher
`/usr/local/bin/turnkey-mysql-install-perf-info-schemas`	75 sh	MySQL schema helper
`/usr/local/sbin/lsof-restart-services`	46 sh	Restarts services holding deleted libraries
`/usr/local/src/tkl-bashlib/*`	3 files	Bash helper library
`/usr/local/bin/basic_passwords.txt`, `vulnerabilities.csv`	418 KB	mysqltuner data files, dropped into `/usr/local/bin`
`/etc/dpkg/origins/TurnKey`	—	Makes `dpkg-vendor` answer `TurnKey` and points bug reports at TurnKey's tracker
`/etc/update-motd.d/00-turnkey-sysinfo`, `07-check-inithooks`, `08-turnkey-confconsole`	—	The login banner chain (#6)
`/etc/sysctl.d/10-hardening-turnkey.conf`, `/etc/ssh/sshd_config.d/turnkey.conf`, `/etc/skel/.bashrc.d/*`	—	Security and shell defaults

Verdict for the category: package them. keel verify (BRIEF 5.4) checks
installed packages against a manifest. A file that no package owns cannot be
verified, cannot be upgraded without a full image rebuild, and survives
removal of the thing it belongs to. This is a real gap in the sovereignty
story and it is cheap to close: one keel-core-tools package, plus moving
/etc/dpkg/origins/TurnKey to /etc/dpkg/origins/keel.

Why confconsole and inithooks are not Debian candidates

These are the two the question is most arguable about, so they get the
detail. Neither verdict is about the idea; a first-boot hook runner and a
terminal config console are both perfectly general ideas. The verdict is
about these implementations.

First, a point that applies to both and that outranks the technical ones.
Both are actively maintained upstream. In 2026 alone: confconsole 50
commits, last on 2026-07-27; inithooks 98 commits, last on 2026-08-19. These
are not abandoned projects we would be rescuing. Proposing another project's
live software to Debian, from our fork, under a name of ours, without them
asking, would be a discourtesy that also happens to be bad engineering: the
Debian package would drift from the upstream that keeps moving, and we would
own the difference forever. If either of these belongs in Debian, the person
to propose it is their maintainer, and the useful thing we can do is the
thing #3 already tracks: send the defects back.

confconsole. What disqualifies it is concrete, not aesthetic:

The usage screen hardcodes https://hub.turnkeylinux.org and the string
"TurnKey Backups and Cloud Deployment" as trailing lines, and shells out to
tklbam-status --short to fill a block above them.
dehydrated-wrapper hardcodes SERVICES_TO_RESTART="webmin.service".
The DNS-01 plugin depends on /usr/bin/turnkey-lexicon, which confconsole
itself ships, and which is a bash wrapper that execs lexicon out of a pip
virtualenv at /usr/local/src/venv. A Debian package may not depend on
software installed by pip outside dpkg. This alone ends the conversation.
Licence defect: debian/copyright declares GPL-3+ for the whole
source. Three files (plugins.d/Lets_Encrypt/dehydrated-wrapper,
add-water-client, add-water-srv) are AGPL-3+. Both are DFSG-free,
so this is not a freeness problem, but the copyright file is wrong and
Debian would reject it on that. It also bears on our own decision 0007,
which says AGPL code cannot move into the GPL-3 forks: it already has.

Generalising past all of that is not a small change, and what is left after
removing the Hub block, the tklbam block, the webmin restart and the lexicon
venv is not confconsole any more. It is Keel's console, which is what the
brief asks for anyway (section 6). We have already added keelbanner,
keelcli and the Instance menu, and taken the repository from no tests at
all to 3,775 lines of them. Keep it, own it, rename it.

inithooks. GPL-2+, which is fine. What is not:

It Depends: turnkey-ssl and Recommends: confconsole, so it drags the
whole set with it.
firstboot.d/80hub-services initialises tklbam and hubdns against the Hub.
firstboot.d/29tagid appends
<script src="https://ajax.turnkeylinux.org/initfence/..."> to the page
served on first boot, so a freshly built appliance loads remote JavaScript
from TurnKey's CDN before the operator has logged in. The hub inventory
calls this "cosmetic and removable"; it is also the clearest thing on this
list that has to go before we ship to anyone.
It writes /var/lib/turnkey-info and ships turnkey-init,
turnkey-init-fence, turnkey-sudoadmin.

The deeper objection is that Debian's answer to "run configuration once at
first boot" is cloud-init, which is in Debian, is vastly more capable, and
is what any reviewer would point at. We would be proposing a second, smaller,
distribution-specific one. The defensible position is the opposite of
upstreaming: keep it, and let the declarative spec (BRIEF 5.2) be the thing
that makes it worth keeping.

Defects found while measuring

These are not packaging opinions, they are things that are wrong right now.
Each should become its own issue; listing them here so they are not lost.

turnkey-ssl ships a private key. /usr/share/turnkey-ssl/cert.key
and cert.pem are in the .deb, identical on every appliance that installs
it. The certificate is O=TurnKey GNU/Linux, OU=Software appliances, CN=tkldev, valid Aug 19 2015 to Aug 19 2025 — expired over a year
ago. firstboot.d/15regen-sslcert regenerates on first boot, so the
window is narrow, but the key is published, shared, and shipped.
A 2010 Squid on every appliance. tklbam depends on tklbam-squid
and vendors the binary into /usr/lib/tklbam/deps. Squid 2.7.STABLE9 has
not had a security fix in over a decade. Debian trixie has Squid 6.
Python 2 in the base layer. turnkey-pypy2, 41 MB, exists only
because tklbam still runs Python 2 code (py2_duplicity.py).
First-boot page loads remote JavaScript from ajax.turnkeylinux.org
(inithooks/firstboot.d/29tagid).
The archive is plain HTTP and signed with a key we do not hold.

Items 1 to 4 all disappear if the verdicts above are carried out, which is
the strongest argument for doing so.

What Debian actually costs, unsentimentally

The received wisdom here is out of date and I want to correct it before using
it, because the correction does not help our case, it sharpens it.

For a new source package, from someone who is not a Debian Developer:

ITP bug against the wnpp pseudo-package. Free, takes minutes
(reportbug wnpp, copy debian-devel with X-Debbugs-CC:, close it from
debian/changelog).
A policy-compliant source package. Current Policy is 4.7.4.1
(2026-03-31). Two things commonly asserted are not actually normative:
DEP-5 machine-readable copyright says of itself "Use of this specification
is optional", and there is no rule anywhere requiring lintian-clean. Both
are sponsor practice, which in practice means they are required anyway.
Days to weeks of work.
A sponsor. This is the wall.
The NEW queue. This is no longer the wall, and anyone reasoning from
memory will get this wrong. Following the October 2025 split of ftpmaster
into an Archive Operations team and a DFSG/Licensing/New Packages team,
the queue went from 750+ packages to normally under 30, processed in two
or three days; median wait is now under 48 hours. Measured on 2026-09-28:
38 sources in NEW, oldest one month.

So the cost is concentrated in one place. Open sponsorship-requests bugs
on 2026-09-28: 94. Median age 53.5 days. Mean 119 days. Maximum 1,973 days —
#988010 has been waiting since May 2021. Sixty-eight of the 94 are ITPs,
that is, exactly our case: a new package from someone without upload rights.

And it does not end at the first upload. Debian Maintainer status cannot
help here: DM upload rights are granted per-package, by a DD, and only for
packages that do not pass through NEW. The first upload of any new source
package must come from a full Developer, every time.

Then the part nobody budgets for: autoremoval. An RC bug present in both
testing and unstable marks the package after 14 days and removes it about ten
days later. The current list has 8,917 entries, most of them transitive:
your package is dragged out of testing by somebody else's RC bug somewhere in
your dependency chain, on a clock you do not control. And the forky freeze
dates are all still "TBA"; the milestone that matters is the soft freeze,
after which new packages cannot enter testing at all, so "we will do it
before the freeze" is not a plan you can schedule against.

Against all of that, a wishlist bug with a patch against an existing package
costs one bug report and a conversation with one maintainer who already owns
the code, and carries no maintenance obligation whatsoever. That is why both
shortlist items are patches and neither is a package.

Where I am uncertain, and what would settle it

Whether Debian's dhcpcd maintainer wants the ifupdown glue at all.
I confirmed the gap exists (dhcpcd-base in trixie ships no
/etc/network/if-*.d hooks). I did not confirm that the maintainer would
welcome filling it: dhcpcd and ifupdown are somewhat rival approaches and
he may reasonably say "use one or the other". Settled by asking on the
Debian bug before writing anything. If the answer is no, the verdict
becomes Keel package and the shortlist drops to one item.
tkl-installer. I judged it not-yet on age and risk, not on quality: I
read its structure but did not audit its partitioning logic and found no
test suite. If Keel goes LXC and Proxmox only, the answer is simply drop.
That turns on whether we keep shipping an ISO, which is a maintainer
question, not a packaging one.
The licence of turnkey-keys and the turnkey-*-19.0 metapackages is
unstated in their copyright files. It stops mattering the moment we drop
them, which is the recommendation, but it would matter if anyone wanted to
keep them.
Whether tklbam's filesystem-delta idea is worth reimplementing.
Debian has debsums, cruft, cruft-ng and dpkg --verify, but nothing
combines dpkg-delta plus duplicity plus database dumps; that composition is
genuinely tklbam's own and it is the part of BRIEF 5.2 that the instance
spec inherits. I am recommending we drop the packaging, not the idea, but
I have not costed rebuilding the idea.
Squid 2.7's actual justification. I have not established why TurnKey
pinned 2.7 rather than a current Squid. The commonly cited reason
(store-URL rewriting) does not hold up: that feature was ported to Squid
3.4 as StoreID and store_id_program is present in trixie's Squid 6.13.
What genuinely did not survive is COSS and a few HTTP-violating
refresh_pattern knobs. This only matters if someone argues to keep it; I
am arguing to delete it.

Two things I deliberately did not rely on, and would want checked before
they are quoted anywhere: that agetty's \4 / \6 issue escapes are an
adequate replacement for turnkey-netinfo in the banner (plausible, not
verified here), and the precise removal versions for the Squid
refresh_pattern options above.

Suggested order

File the two Debian patches. Cheapest, and they are the only things here
that are actually contributions.
Drop tklbam, tklbam-squid, turnkey-pypy2, hubdns, webmin-tklbam
from common/plans/turnkey/base. That is one edit and it removes four of
the five defects above, roughly 50 MB, and a Python 2 interpreter.
Rebuild turnkey-ssl as keel-ssl without the shipped key.
Replace turnkey-netinfo, turnkey-conffile and py3curl-wrapper with
their Debian equivalents inside the keel library.
Package the fourth category as keel-core-tools.
keel-version and keel-sysinfo per #13; keel-confconsole and
keel-inithooks after, since they touch the whole layer chain.
Decide about Webmin, in a decision note.

Only after all of that is archive.turnkeylinux.org removable from
bootstrap_apt, which is the actual goal.

Every Keel appliance built today still resolves packages from `archive.turnkeylinux.org`, over plain HTTP, verified with a key that is not ours. This note enumerates what actually comes from there, and says for each one whether it should go to Debian, into our archive, or nowhere. The short answer to the question as asked: **almost nothing here should become a new Debian source package.** One item is worth sending to Debian now, and it should go as a patch to a package Debian already has, not as a new one. That route costs no ITP, no sponsor and no NEW queue. ## Ground truth Measured 2026-09-28 on four containers on the build host (`wordpress-demo`, `forum`, `forum2`, `tkl-core-bench`), cross-checked against `common/plans/turnkey/base`, which is where these packages actually enter a build. Nothing was modified; no build was started. The appliance carries two enabled sources it does not own: ``` /etc/apt/sources.list.d/sources.sources /etc/apt/sources.list.d/security.sources.sources URIs: http://archive.turnkeylinux.org/debian Signed-By: /usr/share/keyrings/tkl-archive-keyring.gpg ``` Both are plain HTTP, and the keyring comes from `turnkey-keys`, a package from that same archive. A third, `turnkey-testing.sources`, is present and disabled. Decision 0012 already records the consequence: that archive keeps no snapshots, so a version we pin today is unfetchable within weeks, and the rebuild promise cannot be kept while any part of the image comes from there. `dpkg-vendor --query Vendor` on a Keel appliance still answers `TurnKey`, and apt announces itself to every archive it contacts as `TurnKey APT-HTTP/1.3 (turnkey-wordpress-19.0-trixie-amd64)`. ## The shortlist, and how many is realistic **One, going to Debian as a patch rather than a package. Possibly a second. Zero new Debian source packages this cycle.** Proposing a package to Debian is a standing maintenance obligation, and this project has one maintainer who is not a Debian Developer. The honest capacity is one contribution that lands and stays landed, not a portfolio. 1. **`tkl-dhcpcd-ifupdown-glue`** — 119 lines of clean bash, GPL-3+, written 2026, with exactly one TurnKey string in it (a comment). Its `if-pre-up` and `if-post-down` hooks write and remove `noipv4` / `noipv6` deny stanzas in `dhcpcd.conf` so that dhcpcd, running as a system daemon, stops claiming interfaces that `/etc/network/interfaces` declares static. Be precise about the gap, because it is narrower than it first looks. `ifupdown` 0.8.44 already knows about dhcpcd: its `inet dhcp` method falls back dhclient → udhcpc → dhcpcd. `ifupdown-ng` 0.12.1 probes `/sbin/dhcpcd` *first* in `determine_implementation()`. So "ifupdown cannot drive dhcpcd" is false. What is true is that **`dhcpcd-base` in trixie ships zero files under `/etc/network`** (verified against its file list: only `/etc/dhcpcd.conf`, `/usr/lib/dhcpcd/dhcpcd-hooks/*` and `/usr/share/dhcpcd/hooks/*`), so when dhcpcd runs as a daemon in parallel with ifupdown, nothing tells it to keep its hands off the static interfaces. That is the actual gap and that is what these 119 lines fill. Too small to justify its own source package. The right destination is a wishlist bug with a patch against Debian's `dhcpcd`. No ITP, no sponsor, no NEW queue, and if it is accepted we delete a package instead of gaining one. 2. **The SAN and wildcard handling in `turnkey-make-ssl-cert`** (from `turnkey-ssl`) — Debian's `ssl-cert` 1.1.3 ships `make-ssl-cert`, which generates snakeoil self-signed certs and nothing more. The delta (subject alternative names, wildcards, IP SANs, CSR output) is a genuine gap and is offerable as a wishlist bug with a patch against `ssl-cert`. Second cheapest thing on this list. The rest of `turnkey-ssl` must not be offered to anybody, for the reason in the defects section below. Everything else is either ours to keep, or ours to delete. Worth stating plainly, because it bears on all of this: **none of these thirteen TurnKey-named packages exists in Debian, and not one of them has ever had a wnpp bug** — no ITP, no RFP, open or archived. Nobody has ever asked Debian for any of them. That is not an opening; it is a signal about demand. ## Full verdict table `LOC` counts code, not tests or packaging. ### TurnKey-authored, from TurnKey's archive | Package | What it does (from the code) | LOC | Licence | Verdict | Reason | |---|---|---|---|---|---| | `tkl-dhcpcd-ifupdown-glue` 0.1.3 | ifupdown pre-up/post-down hooks that add or remove `noipv4`/`noipv6` stanzas in `dhcpcd.conf` so dhcpcd leaves statically configured interfaces alone | 119 sh | GPL-3+ | **Debian** | Generic, tiny, clean; goes as a patch to Debian's `dhcpcd`, not a new package | | `turnkey-ssl` 3.1.1 | `turnkey-make-ssl-cert`: an openssl wrapper that builds self-signed certs with SANs and wildcards, and concatenates cert+key+dhparams into one PEM | 414 sh | GPL-3+ | **Keel** (SAN delta to Debian as a patch) | Ships a private key in the .deb; see defects | | `confconsole` 2.2.3 | The tty1 TUI: usage screen with addresses and service URLs, plus plugins for networking, region, proxy, mail relay, security updates and Let's Encrypt | 4,650 py + 753 sh | GPL-3+, **three files AGPL-3+** | **Keel** | Already diverged; and it is not packageable as-is, see below | | `inithooks` 2.3.6 | systemd unit on tty1 that runs `firstboot.d/` once and `everyboot.d/` each boot, sourcing `/etc/inithooks.conf`, with dialog and preseed modes | 2,449 py + 1,621 sh | GPL-2+ | **Keel** | The idea is generic; this implementation is not, and Debian's answer is `cloud-init` | | `tkl-installer` 0.1.2 | Minimal CLI installer for Debian live systems: disk detection, partitioning, formatting, rootfs copy, grub. Replaces d-i on the ISO | 4,461 py | GPL-3+ | **Keel**, or drop | Debian already has `debian-installer-launcher` 44 and `calamares` 3.3.14, so this is not a gap. New in 2026, unproven, partitions disks as root | | `turnkey-netinfo` 1.1.1 | Interface and address enumeration via raw `ioctl` (`SIOCGIFADDR` and friends) | 232 py | GPL-3+ | **Drop** | IPv4-era ioctl wrapper; `python3-psutil` and `python3-pyroute2` are in Debian and do it properly. For the banner case, `agetty` already expands `\4` and `\6` in `/etc/issue` | | `turnkey-conffile` 1.1.2 | A `dict` subclass that reads and writes `KEY=value` shell-style config files with attribute access | 97 py | GPL-3+ | **Drop** | 97 lines; fold into the `keel` library or use `python3-dotenv` | | `py3curl-wrapper` 2.1.2 | A requests-shaped API over pycurl | 259 py | GPL-2+ | **Drop** | `python3-requests` exists; and this one reads `/etc/apt/apt.conf.d/01turnkey` to put the appliance build ID in its User-Agent | | `hubdns` 1.4.0 | Dynamic DNS client that registers the appliance against the TurnKey Hub API, on an hourly cron | 294 py | GPL-3+ | **Drop** | Hub-specific by definition; decision 0002 defers the Hub. `ddclient` and `inadyn` are in Debian | | `tklbam` 1.5.3 | Backup and migration: diffs the filesystem against pristine dpkg state, dumps MySQL/PostgreSQL, drives duplicity, and talks to the Hub | 10,234 py **+ 7.2 MB vendored** | GPL-3+ | **Drop as packaged** | See defects. Decision 0002 defers it; the idea inside it is worth keeping as new code | | `tklbam-squid` / `-common` | Squid **2.7.STABLE9**, vendored into `/usr/lib/tklbam/deps/usr/sbin/squid` as tklbam's package-download cache | (2010 upstream) | GPL-2 | **Drop, first** | A 16-year-old unpatched proxy on every appliance. Debian trixie has Squid 6.13; no squid 2.x exists anywhere in Debian | | `turnkey-pypy2` 7.3.23 | A 41 MB PyPy **2.7** interpreter, installed solely so tklbam can run Python 2 code | 41 MB binary | MIT (PyPy) | **Drop** with tklbam | PyPy 2 is not in Debian at all, and `python2.7` is gone from trixie. We are carrying a Python 2 runtime Debian deliberately removed | | `turnkey-keys` 0.1 | TurnKey's APT and image signing keyrings, buster through trixie | keys only | unstated | **Drop** | `keel-archive-keyring` already replaces it | | `turnkey-version` 1.1.3 | `/usr/bin/turnkey-version`, python module `sysversion` | — | GPL-3+ | **Keel** | Already decided, #13 | | `turnkey-sysinfo` 1.1.0 | `turnkey-sysinfo`, `turnkey-detect-virt`, module `libsysinfo` | — | GPL-3+ | **Keel** | Already decided, #13 | | `turnkey-core-19.0`, `turnkey-<app>-19.0` | Empty release-marker metapackages | 0 | unstated | **Keel** | Rename to `keel-*`; some are already built by us | ### Repackaged, not TurnKey's to give and not ours | Package | What it is | Verdict | Reason | |---|---|---|---| | `webmin` + 25 `webmin-*` modules | Upstream Webmin, re-split by TurnKey from the `webmin-minimal` and full tarballs into a core package plus one package per module. 150 MB of source. Unmodified upstream code plus packaging | **Keel if we keep it, but decide whether to keep it** | Not ours to upstream, and Debian's absence of Webmin is a deliberate position, not a gap waiting to be filled | | `webmin-tklbam` 1.2.1 | A single `tklbam.wbm.gz` Webmin module for tklbam | **Drop** | Follows tklbam | The Webmin question deserves its own decision note rather than a line in a table, and the reason Debian does not have Webmin is the most useful thing I found while measuring. **Webmin is not missing from Debian. It was thrown out, by its own maintainer, and three attempts to bring it back have failed over twenty years.** Note that the widely repeated "Debian dropped Webmin for security reasons" story is not what the record says, and we should not repeat it. There is no DFSG or licence ruling against Webmin anywhere. - Packaged from 2000 ([#75030](https://bugs.debian.org/75030) ITP) by **Jaldhar H. Vyas**. Shipped through sarge. - [**#271505**](https://bugs.debian.org/271505) (Sep 2004) RFA: webmin. No taker for fifteen months. - [**#343897**](https://bugs.debian.org/343897), 2005-12-18, *"ftp.debian.org: Please remove all webmin related packages"*, filed by Vyas himself and executed by Joerg Jaspert on 2006-01-12. Sarge had carried **65 `webmin*` binary packages** on i386 alone. The machine-readable reason in the archive removal log is **`RoM; outdated; unmaintained`** — note, *not* security. Vyas's own words: *"less and less time and motivation to keep at it"*; *"I have always been more or less the only person looking after them"*; **"It is better to drop them now rather than perpetrate the cruel joke that these are Debian-quality packages"**; and *"we owe it to Jamie Cameron, the author of webmin, not to besmirch his name and product with buggy crap."* Asked why he would not simply orphan them, he said orphaning had produced *"an initial flurry of interest that rarely panned out"*. The removal was copied to debian-devel and **drew no replies at all**. - [**#377948**](https://bugs.debian.org/377948) (Jul 2006) ITP: webmin. Upstream author Jamie Cameron took part personally. It stalled on packaging basics (a `DEBIAN/` directory instead of `debian/`, so `dpkg-buildpackage` would not run; `/etc/webmin` generated at install time rather than shipped). **Closed 2010-01-09** by Steffen Joeris of the security team: *"There hasn't been any progress on this ITP for quite a long time and webmin continues to receive CVE ids, which we (security team) need to track in our tracker because of this ITP."* - [**#820659**](https://bugs.debian.org/820659), filed 2016, is **still open today** as an RFP. It briefly became an ITP and was reverted to RFP in February 2024 when the prospective maintainer gave up. His parting assessment is the most useful sentence in the whole file: **"webmin is the most awkward and terrible project I've ever seen, which contains tons of outdated sources and countless fixed paths."** - That same attempt produced the **vendored-code evidence**, in RFS [**#880590**](https://bugs.debian.org/880590). Emmanuel Bourg, 2018-01-16: *"I think getting rid of the prebuilt binaries will be required to upload it. The flashterm, ftelnet and shellinabox directories could probably be removed from the upstream tarball […] out of the embedded .jar files it seems only jta26.jar is actually used […] (however I question the relevance of embedding a Java applet in 2018 now that this technology has been removed from all major browsers)."* The request was duly retitled `webmin/1.870-1` → `webmin/1.870+ds-1`: a repack was mandatory. Andrey Rahmatullin, 2017-11-06: *"The package has lots of lintian-detected problems, some of them critical."* The RFS timed out and was closed in October 2018. That attempt would have produced roughly **150 binary packages**. - **Upstream's own answer**, Jamie Cameron, asked in July 2025 why cockpit is in Debian and Webmin is not: *"Honestly we never really looked into it, and found it easier to just create our own repository that we can push updates to via our own release processes."* - **The security load, for scale:** Debian's security tracker carries 96 CVE entries mentioning Webmin, 86 of them marked `<removed>`, of which **seven were assigned in 2026 alone**. While it was in the archive it cost five DSAs. - `usermin` and `virtualmin` are not in Debian either and have no current wnpp bug. Virtualmin only ever existed as `webmin-virtual-server`, removed with the rest in January 2006. - `cockpit` **is** in Debian: 337-1+deb13u2 in trixie, with security updates, 368-1 in forky/sid. Read that against our situation. The reasons Webmin is not in Debian are: one maintainer could not sustain it, the tree is large and carries prebuilt binaries and hardcoded paths, and it accumulates CVEs faster than a volunteer can track them. We have one maintainer. We ship **26** Webmin packages in the base layer of every appliance, rebuilt by a third party whose archive keeps no snapshots (decision 0012). Every reason Debian has for not carrying Webmin applies to us, with fewer people. To be scrupulous about what is and is not sourced here: I could find **no Debian developer on record** saying Webmin was rejected for fighting the distribution's configuration management, and no licence or DFSG objection to Webmin itself (it is BSD; the 2018 repack demand was about prebuilt binaries, which is source cleanliness, not licensing). The sourced objections are sole-maintainer burnout, staleness, prebuilt binaries, hardcoded paths and CVE volume. That is enough on its own; we do not need the stronger claim and should not make it. **On cockpit as the alternative, honestly.** It is in Debian (trixie 337-1+deb13u2 with security updates, 368-1 in forky), maintained by the Utopia Maintenance Team, and split into nine binary packages. It is architecturally the thing Debian wanted: it drives existing system D-Bus APIs instead of parsing and rewriting each service's config files, authenticates real system users through PAM instead of keeping its own password store, and is fine-grained rather than monolithic. But it is **not a feature superset**, and anyone proposing a swap has to own that: Debian has no cockpit module for BIND, Postfix, Exim, Samba, Squid, ProFTPD, DHCP or Apache, all of which Webmin covers and several of which our appliances are built around. I am therefore not recommending a Webmin verdict here, because it is a product decision and not a packaging one: for a lot of appliance users the Webmin panel *is* the product. I am recommending that the decision be *made*, deliberately, written down, and costed against that gap list rather than against a slogan. ### Fourth category: TurnKey-authored files in no package at all Written into the image at build time by `common/conf/turnkey.d/*` and `common/overlays/turnkey.d/*`, owned by no package, therefore not upgradeable, not verifiable and not removable: | File | Lines | What it is | |---|---|---| | `/usr/local/bin/apt-packages-origin` | 84 py | Parses `apt-cache policy` to report which archive each package came from | | `/usr/local/bin/gh_releases` | 124 sh | Queries the GitHub releases API | | `/usr/local/bin/turnkey-php` | 54 sh | PHP version switcher | | `/usr/local/bin/turnkey-mysql-install-perf-info-schemas` | 75 sh | MySQL schema helper | | `/usr/local/sbin/lsof-restart-services` | 46 sh | Restarts services holding deleted libraries | | `/usr/local/src/tkl-bashlib/*` | 3 files | Bash helper library | | `/usr/local/bin/basic_passwords.txt`, `vulnerabilities.csv` | 418 KB | mysqltuner data files, dropped into `/usr/local/bin` | | `/etc/dpkg/origins/TurnKey` | — | Makes `dpkg-vendor` answer `TurnKey` and points bug reports at TurnKey's tracker | | `/etc/update-motd.d/00-turnkey-sysinfo`, `07-check-inithooks`, `08-turnkey-confconsole` | — | The login banner chain (#6) | | `/etc/sysctl.d/10-hardening-turnkey.conf`, `/etc/ssh/sshd_config.d/turnkey.conf`, `/etc/skel/.bashrc.d/*` | — | Security and shell defaults | **Verdict for the category: package them.** `keel verify` (BRIEF 5.4) checks installed packages against a manifest. A file that no package owns cannot be verified, cannot be upgraded without a full image rebuild, and survives removal of the thing it belongs to. This is a real gap in the sovereignty story and it is cheap to close: one `keel-core-tools` package, plus moving `/etc/dpkg/origins/TurnKey` to `/etc/dpkg/origins/keel`. ## Why confconsole and inithooks are not Debian candidates These are the two the question is most arguable about, so they get the detail. Neither verdict is about the idea; a first-boot hook runner and a terminal config console are both perfectly general ideas. The verdict is about these implementations. First, a point that applies to both and that outranks the technical ones. **Both are actively maintained upstream.** In 2026 alone: confconsole 50 commits, last on 2026-07-27; inithooks 98 commits, last on 2026-08-19. These are not abandoned projects we would be rescuing. Proposing another project's live software to Debian, from our fork, under a name of ours, without them asking, would be a discourtesy that also happens to be bad engineering: the Debian package would drift from the upstream that keeps moving, and we would own the difference forever. If either of these belongs in Debian, the person to propose it is their maintainer, and the useful thing we can do is the thing #3 already tracks: send the defects back. **confconsole.** What disqualifies it is concrete, not aesthetic: - The usage screen hardcodes `https://hub.turnkeylinux.org` and the string "TurnKey Backups and Cloud Deployment" as trailing lines, and shells out to `tklbam-status --short` to fill a block above them. - `dehydrated-wrapper` hardcodes `SERVICES_TO_RESTART="webmin.service"`. - The DNS-01 plugin depends on `/usr/bin/turnkey-lexicon`, which confconsole itself ships, and which is a bash wrapper that execs `lexicon` out of a pip virtualenv at `/usr/local/src/venv`. A Debian package may not depend on software installed by pip outside dpkg. This alone ends the conversation. - **Licence defect:** `debian/copyright` declares GPL-3+ for the whole source. Three files (`plugins.d/Lets_Encrypt/dehydrated-wrapper`, `add-water-client`, `add-water-srv`) are **AGPL-3+**. Both are DFSG-free, so this is not a freeness problem, but the copyright file is wrong and Debian would reject it on that. It also bears on our own decision 0007, which says AGPL code cannot move into the GPL-3 forks: it already has. Generalising past all of that is not a small change, and what is left after removing the Hub block, the tklbam block, the webmin restart and the lexicon venv is not confconsole any more. It is Keel's console, which is what the brief asks for anyway (section 6). We have already added `keelbanner`, `keelcli` and the Instance menu, and taken the repository from **no tests at all** to 3,775 lines of them. Keep it, own it, rename it. **inithooks.** GPL-2+, which is fine. What is not: - It `Depends: turnkey-ssl` and `Recommends: confconsole`, so it drags the whole set with it. - `firstboot.d/80hub-services` initialises tklbam and hubdns against the Hub. - `firstboot.d/29tagid` appends `<script src="https://ajax.turnkeylinux.org/initfence/...">` to the page served on first boot, so a freshly built appliance loads remote JavaScript from TurnKey's CDN before the operator has logged in. The hub inventory calls this "cosmetic and removable"; it is also the clearest thing on this list that has to go before we ship to anyone. - It writes `/var/lib/turnkey-info` and ships `turnkey-init`, `turnkey-init-fence`, `turnkey-sudoadmin`. The deeper objection is that Debian's answer to "run configuration once at first boot" is `cloud-init`, which is in Debian, is vastly more capable, and is what any reviewer would point at. We would be proposing a second, smaller, distribution-specific one. The defensible position is the opposite of upstreaming: keep it, and let the declarative spec (BRIEF 5.2) be the thing that makes it worth keeping. ## Defects found while measuring These are not packaging opinions, they are things that are wrong right now. Each should become its own issue; listing them here so they are not lost. 1. **`turnkey-ssl` ships a private key.** `/usr/share/turnkey-ssl/cert.key` and `cert.pem` are in the .deb, identical on every appliance that installs it. The certificate is `O=TurnKey GNU/Linux, OU=Software appliances, CN=tkldev`, valid `Aug 19 2015` to **`Aug 19 2025`** — expired over a year ago. `firstboot.d/15regen-sslcert` regenerates on first boot, so the window is narrow, but the key is published, shared, and shipped. 2. **A 2010 Squid on every appliance.** `tklbam` depends on `tklbam-squid` and vendors the binary into `/usr/lib/tklbam/deps`. Squid 2.7.STABLE9 has not had a security fix in over a decade. Debian trixie has Squid 6. 3. **Python 2 in the base layer.** `turnkey-pypy2`, 41 MB, exists only because tklbam still runs Python 2 code (`py2_duplicity.py`). 4. **First-boot page loads remote JavaScript** from `ajax.turnkeylinux.org` (`inithooks/firstboot.d/29tagid`). 5. **The archive is plain HTTP** and signed with a key we do not hold. Items 1 to 4 all disappear if the verdicts above are carried out, which is the strongest argument for doing so. ## What Debian actually costs, unsentimentally The received wisdom here is out of date and I want to correct it before using it, because the correction does not help our case, it sharpens it. For a new source package, from someone who is not a Debian Developer: 1. **ITP bug** against the `wnpp` pseudo-package. Free, takes minutes (`reportbug wnpp`, copy debian-devel with `X-Debbugs-CC:`, close it from `debian/changelog`). 2. **A policy-compliant source package.** Current Policy is 4.7.4.1 (2026-03-31). Two things commonly asserted are not actually normative: DEP-5 machine-readable copyright says of itself "Use of this specification is optional", and there is no rule anywhere requiring lintian-clean. Both are sponsor practice, which in practice means they are required anyway. Days to weeks of work. 3. **A sponsor.** This is the wall. 4. **The NEW queue.** This is *no longer* the wall, and anyone reasoning from memory will get this wrong. Following the October 2025 split of ftpmaster into an Archive Operations team and a DFSG/Licensing/New Packages team, the queue went from 750+ packages to normally under 30, processed in two or three days; median wait is now under 48 hours. Measured on 2026-09-28: **38 sources in NEW, oldest one month.** So the cost is concentrated in one place. **Open `sponsorship-requests` bugs on 2026-09-28: 94. Median age 53.5 days. Mean 119 days. Maximum 1,973 days — #988010 has been waiting since May 2021.** Sixty-eight of the 94 are ITPs, that is, exactly our case: a new package from someone without upload rights. And it does not end at the first upload. **Debian Maintainer status cannot help here**: DM upload rights are granted per-package, by a DD, and only for packages that do not pass through NEW. The first upload of any new source package must come from a full Developer, every time. Then the part nobody budgets for: **autoremoval**. An RC bug present in both testing and unstable marks the package after 14 days and removes it about ten days later. The current list has 8,917 entries, most of them transitive: your package is dragged out of testing by somebody else's RC bug somewhere in your dependency chain, on a clock you do not control. And the forky freeze dates are all still "TBA"; the milestone that matters is the soft freeze, after which new packages cannot enter testing at all, so "we will do it before the freeze" is not a plan you can schedule against. Against all of that, a wishlist bug with a patch against an existing package costs one bug report and a conversation with one maintainer who already owns the code, and carries no maintenance obligation whatsoever. That is why both shortlist items are patches and neither is a package. ## Where I am uncertain, and what would settle it - **Whether Debian's `dhcpcd` maintainer wants the ifupdown glue at all.** I confirmed the gap exists (`dhcpcd-base` in trixie ships no `/etc/network/if-*.d` hooks). I did not confirm that the maintainer would welcome filling it: dhcpcd and ifupdown are somewhat rival approaches and he may reasonably say "use one or the other". Settled by asking on the Debian bug before writing anything. If the answer is no, the verdict becomes Keel package and the shortlist drops to one item. - **`tkl-installer`.** I judged it not-yet on age and risk, not on quality: I read its structure but did not audit its partitioning logic and found no test suite. If Keel goes LXC and Proxmox only, the answer is simply drop. That turns on whether we keep shipping an ISO, which is a maintainer question, not a packaging one. - **The licence of `turnkey-keys` and the `turnkey-*-19.0` metapackages** is unstated in their copyright files. It stops mattering the moment we drop them, which is the recommendation, but it would matter if anyone wanted to keep them. - **Whether `tklbam`'s filesystem-delta idea is worth reimplementing.** Debian has `debsums`, `cruft`, `cruft-ng` and `dpkg --verify`, but nothing combines dpkg-delta plus duplicity plus database dumps; that composition is genuinely tklbam's own and it is the part of BRIEF 5.2 that the instance spec inherits. I am recommending we drop the *packaging*, not the idea, but I have not costed rebuilding the idea. - **Squid 2.7's actual justification.** I have not established why TurnKey pinned 2.7 rather than a current Squid. The commonly cited reason (store-URL rewriting) does not hold up: that feature was ported to Squid 3.4 as StoreID and `store_id_program` is present in trixie's Squid 6.13. What genuinely did not survive is COSS and a few HTTP-violating `refresh_pattern` knobs. This only matters if someone argues to keep it; I am arguing to delete it. Two things I deliberately did *not* rely on, and would want checked before they are quoted anywhere: that `agetty`'s `\4` / `\6` issue escapes are an adequate replacement for `turnkey-netinfo` in the banner (plausible, not verified here), and the precise removal versions for the Squid `refresh_pattern` options above. ## Suggested order 1. File the two Debian patches. Cheapest, and they are the only things here that are actually contributions. 2. Drop `tklbam`, `tklbam-squid`, `turnkey-pypy2`, `hubdns`, `webmin-tklbam` from `common/plans/turnkey/base`. That is one edit and it removes four of the five defects above, roughly 50 MB, and a Python 2 interpreter. 3. Rebuild `turnkey-ssl` as `keel-ssl` without the shipped key. 4. Replace `turnkey-netinfo`, `turnkey-conffile` and `py3curl-wrapper` with their Debian equivalents inside the `keel` library. 5. Package the fourth category as `keel-core-tools`. 6. `keel-version` and `keel-sysinfo` per #13; `keel-confconsole` and `keel-inithooks` after, since they touch the whole layer chain. 7. Decide about Webmin, in a decision note. Only after all of that is `archive.turnkeylinux.org` removable from `bootstrap_apt`, which is the actual goal.