Answer first
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.
Confirmed facts
- KDE Neon User Edition is Ubuntu LTS base plus KDE Neon repositories that backport Plasma and related components.
- KDE Neon Developer Edition is provided as Docker images. Using an exact digest tag locks the base OS and Neon packages at build time.
- Neither path publishes an official compatibility matrix for third-party Qt PPAs.
- APT pin priorities control which repository wins for a given package, but they do not prevent ABI incompatibility between a custom Qt build and Plasma.
Likely explanation and risks
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.
Minimal steps for this case
User Edition APT pinning
- Pin Neon repositories to the desired Plasma release with a pin file in
/etc/apt/preferences.d.
- Add the custom Qt PPA, then create a lower-priority pin for it so it only provides packages you explicitly request.
- Install the exact Qt packages by name and version, then hold them.
- Verify selection with
apt policy <package> before and after the pin.
Developer Edition Docker with custom Qt PPA
- Start from a Developer Edition image by digest, not a mutable tag.
- Add the Qt PPA inside the Dockerfile and apply APT pins so only the required Qt packages come from the PPA.
- Install Qt packages with explicit version strings and record the versions in the Dockerfile.
- Build and verify with
docker run --rm <image> apt-cache policy <package> and compare hashes of key binaries across rebuilds.
Long-term repeatability with Ubuntu LTS security updates
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.
kdeneon