Create Task
Maniphest T13500

Don't let users install outdated non-KDE apps in Neon
Open, WishlistPublic
Actions

Description

When people ask me for a KDE distro recommendation, one of the things that causes me to not unhesitatingly reply "KDE Neon!" is how 3rd-party user-facing software is up to two years out-of-date and sometimes broken by Neon-specific packaging changes such as Qt upgrades. I have personally had this happen with Telegram and Virtualbox. However this is only the case for software from the main repo itself; apps from Snap or Flatpak do not suffer from either of these issues. Thankfully both come installed out of the box in Discover.

I would like to recommend that Neon work harder to help users avoid outdated and potentially broken 3rd-party software. This could be done by un-packaging all non-KDE user-facing apps from the Neon repos, or else somehow hiding them from Discover's PackageKit backend.

This way, people would still use the Neon repos to get new KDE apps, but all 3rd-party apps would only be available from the Snap store or Flathub, where they are up to date and cannot be broken by Neon-specific packaging.

This would make Neon close to the perfect distro in my opinion.

Related Objects

ngraham created this task.Aug 14 2020, 4:28 AM
ngraham triaged this task as Wishlist priority.
rikmills added a subscriber: rikmills.Aug 14 2020, 6:05 AM

Mostly covered by T11720

sitter added a subscriber: sitter.Aug 14 2020, 9:04 AM

Aleix and I were talking about this kind of thing a while ago and the only way I could think of is T11720 which is a fairly weak approach in general because people insist on using the CLI and still have the same problem.

The-Feren-OS-Dev added a subscriber: The-Feren-OS-Dev.EditedOct 18 2020, 12:17 PM

To block stuff in APT itself, we could always refer to how Linux Mint blocks 'snapd' in the package 'mintsystem' in Linux Mint 20, but instead limit it to only blocking X (where X = the package needing blocking) package on the 'Ubuntu' component so that if users have external package sources for X package they can still install it from those external package sources. The method Mint uses can be used for any package, in principle.

For instance, here's it used to block qt5-gtk2-platformtheme in Ubuntu's repository:

Package: qt5-gtk2-platformtheme
Pin: release o=Ubuntu
Pin-Priority: -10
sitter added a comment.Oct 19 2020, 1:16 PM

While very nifty that wouldn't improve things a lot. Instead of being not installable we'd make them... not installable ^^

This got me thinking though... an argument could be made that packagekit searches shouldn't return packages that are marked with negative preference. Unlike apt-pkg it doesn't have a concept that splits the package entity from its available versions so when a package id is being listed it is considered available for installation in the packagekit world. For apt this is a bit more nuanced, if you were to -10 texmaker then apt install texmaker would refuse to install it, the user can still select a specific version to override though apt install texmaker=1 priorities never matter when the user selects a version. With all this in mind it doesn't exactly make sense that packagekit would allow you to install a negative priority candidate, and by extension it makes no sense to list them in search results.