Should Turris OS Pull Directly from OpenWrt Upstream Feeds?
The idea isn’t new, but TOS 9.1 just made it more relevant
Turris OS 9.1, released in June 2026, unfroze the upstream OpenWrt feeds for non-NG users. That one change delivered a wave of package updates that had been sitting in OpenWrt’s repositories while Turris users waited for the next TOS rebuild cycle. It was a small architectural concession to the argument that the upstream feed is often good enough — and it landed well.
The longer-running community question is whether Turris should go further: use upstream OpenWrt package repositories as the primary source, then layer a smaller set of Turris-specific packages on top at higher priority. If a package in the Turris feed is identical to what’s upstream, skip the Turris rebuild entirely. Only override when there’s a genuine reason to diverge.
How Turris OS currently handles packages
Turris OS is built on top of OpenWrt. The base system starts as a fork of the OpenWrt source tree, with patches applied on top. The Turris team also maintains their own packages feed — os-packages on GitLab — which bundles everything from board support packages and reForis to backported and patched versions of upstream software.
The build process compiles everything: the base image, the Turris package feed, and any selected upstream OpenWrt packages. Users receive updates through updater-ng, Turris’s own transaction-based package manager, which pulls from compiled Turris feeds rather than directly from OpenWrt’s package servers.
That model carries a real cost. Any upstream fix — a security patch in dnsmasq, a new version of python3, a bug fix in curl — has to wait for Turris to rebuild and publish it. Rebuilding a package that is byte-for-byte identical to the upstream binary wastes build infrastructure and delays users. Not every time, but often enough to matter.
The proposed model: upstream as the base feed
What the community discussion describes is a layered feed architecture. Instead of one Turris-compiled feed containing everything, you’d have:
- Upstream OpenWrt package repositories as the default source
- A smaller Turris-specific feed set to higher priority
- The updater pulls from upstream unless the Turris feed carries a patched or newer version of the same package
OpenWrt’s build system already handles feed priority through feeds.conf: a package found in an earlier-listed feed takes precedence over the same package in a later one. At runtime, /etc/opkg/customfeeds.conf provides a similar mechanism for opkg. Updater-ng works differently from plain opkg, so the exact priority implementation would need specific work there — but the concept is sound.
The Turris team has publicly noted that they try to contribute and cooperate with upstream rather than diverge. This model formalizes that intent at the package level.
Why this is harder than it sounds
Feed priority at install time is the tractable part. The harder problem sits at build time.
Right now Turris controls exactly which version of every package lands on user devices because they compile it all. Switching to upstream binaries for the base means trusting that OpenWrt’s build outputs are ABI-compatible with the Turris base system. Usually they are. Not always. OpenWrt’s kernel version, compiler flags, and libc choices affect every package, and Turris sometimes diverges from these to support older hardware — the Turris 1.x line has been running well past upstream hardware support windows.
Release cadence is another wrinkle. OpenWrt stable branches eventually freeze, but the feeds keep rolling. Turris has to decide whether to track OpenWrt’s feed tip or pin to a snapshot. Tracking tip means faster updates but the occasional broken package. Pinning means lag creeps back in — the same problem this model is trying to solve.
And then there’s testing. Turris’s QA pipeline covers their own compiled output. Once runtime dependencies come from upstream binaries, a regression in any upstream package can reach Turris users without passing through Turris’s own validation. TOS 9.1 demonstrated exactly this: the feed unfreeze came with WiFi regressions that sent some users back to 9.0.6. That’s not a reason to avoid upstream feeds — it’s a reason to have a pinning and testing strategy ready before flipping the switch.
The upstream contribution argument
The second half of the original idea is arguably the more impactful piece: fix things in OpenWrt upstream so both communities benefit immediately, instead of fixing in the Turris fork and hoping the patch eventually propagates.
OpenWrt accepts patches and pull requests through GitHub and its developer mailing list. The contributing guidelines ask that patches apply cleanly to the latest trunk and include a Signed-off-by line. That’s a higher bar than committing to a private fork — but it means the fix is maintained by the upstream community going forward, not by whoever at Turris originally committed it.
A security fix contributed to OpenWrt packages reaches every downstream distribution at once: GL.iNet routers, the entire Turris fleet, plain OpenWrt installations, anything built on that feed. One patch, broad coverage. The economics are hard to argue with.
Turris does contribute upstream — it’s part of their stated philosophy. The practical question is how consistently that happens versus how often a fix lands in the Turris fork first because it’s faster, with upstream contribution as a best-effort follow-up.
What TOS 9.1 actually demonstrated
Unfreezing upstream feeds in 9.1 showed that the Turris team is comfortable letting upstream packages flow through more directly. The packages arriving from OpenWrt aren’t going through a full Turris rebuild cycle — they’re built by OpenWrt’s own infrastructure.
That’s a meaningful shift. It proves the model can work in practice. The WiFi regressions that accompanied the release show where the gaps are: testing coverage and snapshot discipline need to keep pace with the looser coupling to upstream.
TOS 9.1 is both a proof of concept and a cautionary example at the same time.
A realistic incremental path
A full switch to upstream-as-base-feed is a significant project. An incremental approach that avoids a big-bang migration might look like:
- Audit the Turris packages feed and identify which packages are identical to upstream builds with no Turris-specific patches
- For those packages, stop rebuilding and redirect updater-ng at the upstream repository instead
- Keep the Turris feed for board support packages, reForis, updater-ng itself, and any package with a genuine Turris patch
- Automate comparisons between the Turris feed and upstream so new upstream versions get flagged quickly rather than quietly falling behind
The goal isn’t to eliminate the Turris feed. It’s to shrink it to what’s actually Turris-specific. That reduces rebuild load, accelerates the delivery of upstream fixes, and focuses maintenance effort where it genuinely matters.
