Question
User Edition APT pinning vs Developer Edition Docker images for repeatable KDE Neon dev with custom Qt PPA
Rey Dey
0 reputation · 23 Apr 2021, 23:35 UTC
130.1K views1
Loading…
0 reputation · 23 Apr 2021, 23:35 UTC
Create a repeatable KDE Neon development environment that includes a custom Qt build from a third‑party PPA while keeping the Plasma stack stable and reproducible across CI runs.
KDE Neon offers two documented paths: pinning the User Edition APT repositories to a specific Plasma release, or using exact‑tag Developer Edition Docker images. Neither path publishes a compatibility matrix for external PPAs, so it is unclear whether adding a custom Qt PPA will break Plasma ABI or introduce version drift when combined with either approach.
29775 reputation · 24 Apr 2021, 05:48 UTC
Pinning the User Edition on a host can keep Plasma stable, but it does not guarantee safety with a custom Qt PPA. A fixed-digest Developer Edition Docker image can be made repeatable with a custom Qt PPA only if you pin both the base image digest and the exact Qt package versions inside the image. For long-term repeatability with Ubuntu LTS security updates, a version-pinned Docker image that is rebuilt on a schedule is more repeatable than host APT pinning.
APT pinning on a host keeps the Plasma stack on the Neon stream while allowing a Qt PPA to supply selected packages. The host kernel, system libraries and non-KDE packages continue to receive normal Ubuntu updates, which introduces drift over time. Pin priorities can unintentionally hold back security updates if the Qt PPA priority is set too high.
A Docker image encapsulates OS, Neon packages and the Qt PPA in one build. Reproducibility depends on pinning the base image digest and locking package versions. The PPA itself is a moving target: if it publishes new Qt builds, a rebuild will change the environment unless versions are explicitly pinned.
kdeneon/etc/apt/preferences.d.apt policy <package> before and after the pin.docker run --rm <image> apt-cache policy <package> and compare hashes of key binaries across rebuilds.Docker with a pinned digest gives better repeatability because the entire stack is locked. Security updates require a planned rebuild of the image from the same Dockerfile, which produces a new digest you can promote. Host APT pinning inherits the host’s vulnerability state and can drift between CI runs unless the host is recreated from scratch each time.
One missing diagnostic detail that changes the recommendation: is the custom Qt PPA built against the same Ubuntu LTS base and Qt major/minor as the Neon Plasma release you are pinning to, and is it signed and version-stable? If the PPA provides an ABI-incompatible Qt, neither pinning nor Docker will keep Plasma stable, and you should isolate the custom Qt to a build stage only.
Use comments to ask for clarification. Post a solution as an answer.
29,775 reputation · 24 Apr 2021, 02:00 UTC
To bridge the gap between repository pinning and actual runtime stability, it is critical to verify that the custom Qt PPA hasn't introduced a silent ABI mismatch. While APT pinning controls which package is installed, it doesn't guarantee that the resulting binaries are compatible with the existing Plasma stack.
For both the User Edition and Docker-based workflows, you can verify the linked libraries using ldd on a core Plasma binary (e.g., plasmashell). This confirms exactly which libQt version is being loaded at runtime, regardless of what the package manager reports.
Additionally, running apt-cache policy [package-name] for the specific Qt libraries allows you to see the priority values in action. If the PPA priority is higher than the Neon repositories, any security update to a dependency in the Neon stream could still trigger an unexpected upgrade of the Qt stack, potentially breaking the build's repeatability.