KDE Neon: Staying on the Ubuntu LTS Base vs Chasing the Latest Plasma Repo

Answer the questions first

1. Is staying strictly on the LTS base with default pinning the safer choice for update cadence, or does the Neon user repo keep pace with Plasma security fixes well enough to justify freshness?

• Confirmed fact: Ubuntu LTS releases receive regular, long‑term security updates that are thoroughly backported to the base packages. With default pinning (priority 1000 for base, 990 for Neon), the system will prefer base versions whenever a conflict arises.
• Likely explanation: The Neon user repository tracks Plasma and KDE applications closely. Most security patches are merged within a few weeks, but the repo does not backport every LTS security fix to Plasma components. If the base is far behind (e.g., 22.04 + 2‑year gap to 24.04), Plasma may lag in critical fixes until the user repo is updated, potentially leaving the system exposed.
• Practical recommendation: Use the default LTS pinning if you value predictable, tested security updates. If you need the latest KDE features and can tolerate a small window where Plasma lags LTS security patches, keep the Neon repo enabled but monitor the apt list --upgradable output for Plasma packages that are ahead of the base.

2. When the current LTS base nears end‑of‑life, is a clean install genuinely preferable to attempting an in‑place base migration?

• Confirmed fact: KDE Neon maintainers recommend a clean reinstall when moving between LTS releases (e.g., 22.04 → 24.04, 24.04 → 24.10). In‑place upgrades can trigger dependency conflicts between base and user packages because the Neon repo is built against a specific base version.
• Likely explanation: The transition between major LTS releases introduces new library versions, ABI changes, and package renames that the user repo may not yet support. A clean install ensures that the base and Neon packages are aligned from the start.
• Practical recommendation: When the current LTS reaches its EOL (check the Ubuntu EOL schedule), back up your home directory, download the latest Neon ISO for the new LTS, and perform a fresh install. Restore your data and re‑enable the Neon user repo afterward.

3. What is the risk of third‑party PPAs overriding the pinning assumptions and causing unsupported partial upgrades?

• Confirmed fact: PPAs often ignore the default pinning scheme. Packages from a PPA can have a higher priority than the Neon user repo, leading to a mix of base, Neon, and PPA packages that may not be compatible.
• Likely explanation: A PPA that provides a newer KDE component but pulls in a library from a different distribution can break the dependency chain, causing the system to become unstable or preventing future upgrades.
• Practical recommendation: Inspect any PPAs you have installed. Run apt-cache policy <package> for key KDE components and verify that the priority of the PPA is lower than both the base and Neon repos. If not, either remove the PPA or adjust /etc/apt/preferences.d/ to force the desired priority.

Verification steps for your specific setup

1. Check the priority of your Plasma packages:

   apt-cache policy plasma-workspace
   

2. List pending upgrades and see which repo they come from:

   apt list --upgradable
   

3. Inspect custom pinning files:

   ls /etc/apt/preferences.d/
   

4. If you have PPAs, verify their priority relative to the base and Neon repos. Adjust or remove as needed.

Missing diagnostic detail

To tailor the recommendation on clean install timing, please let me know which Ubuntu LTS version you are currently running (e.g., 22.04 LTS, 24.04 LTS).