In Discover add a little explanation of each packaging format to not confuse new Linux users

Brainstorm
1

I see this a lot when talking to new Linux users, and the latest LTT Linux Challenge Part 2 highlighted this issue.

When opening Discover and selecting a piece of software, if you have more than one backend enabled (for example repo and Flatpak) you are presented with a selection list of sources for this package.

We of course all know what’s the difference between “Install From Fedora Linux”, “Install From Flatpak” and “Install From Snap”, but a new Linux user often gets confused, as they don’t really know what these mean. No distro or DE bothers to explain the packaging formats, and even if a user is willing to learn about them, installing some basic programs is most commonly the first thing you do after OS installation.

I would like to suggest adding a little (?) icon next to the selection list, or some other indicator of “Here you can get help”. Upon clicking on this icon, or hovering over it, it should explain the general difference between package from repositories, package from Flatpak or Snap.

The most important thing - these should explain packaging in simple, easy to understand way, so to not confuse the user even more. For example, for repo packages:

“This package comes from your distribution’s repository. It is packaged and tested by the maintainers of the distribution, which may not be the original creators. If you’re using an LTS distribution, this version of the package may be older than the most recent release”

Of course this is only my proposition, I’m sure someone smarter than me could come up with better explanation, but the idea is there.

One more thing - this is not intended to be hand-maintained for every package, every packaging format, etc. It’s meant to be a general, distro-agnostic and application-agnostic information. Sort of like “The terminal emulator is used for typing in terminal commands”.

Cheers!

3 Likes
2

hi, welcome.

this would seem like a good idea and welcome improvement to discover.

it could be as simple as an ⓘ icon that appears next to and along with the Sources drop down (i.e would not show at all if Sources were not triggered).

hovering over the tooltop could say “Shift for more information” as i’ve seen in several other places within the plasma desktop environment (settings, etc).

then when hover+shift is selected a few paragraphs explaining the different sources could be shown.

perhaps it can even hit at how to enable additional backends such as flatpak which didn’t come install by default with my kubuntu distro.

3

I don’t think this should require any additional action from the user - like clicking Shift. Sure, for us this would feel natural, but for new user, they could simply not notice.

Maybe instead a popup should show up when hovering over the “Install from …” button with the explanation, instead of current one, which just repeats the text on the button?

2 Likes
4

then again, the people who actually need to read those never do

perhaps we can make seperate the welcome screen into two parts,
the main one and another for discover which appears inside the discover window?

it will contain the enable third-party repo button, and quick guide to installing app not only with discover but also via cli

it might be a bad idea, but hay :sheaf_of_rice:, it is an idea ¯\_(ツ)_/¯

2 Likes
5

That’s certainly AN idea. It may be actually a good one. Some cute Konqi image with “Hey! Want to know how to install new applications?” and like 1-2 pages, detailing how to use Discover, and maybe a distro-customizable link to documentation explaining how to do the same in the terminal (remember, we want to make this distro-agnostic).

However, I can see annoyed Arch users screaming at their monitors already, that after fresh install they have to click through another welcome window…

1 Like
6

i missedm this entirely, thats basicly what im going for. something you cant miss

7

i dont really like arch users who do that, it may be 2 clicks for them, but hours of begging for help for someone’s grandma.

Anyhow, this actually makes it better for arch users, they dont use the discover store anyways and when the main welcome screen shows, it will need less pages to load and hence be 0.000234 attoseconds faster when booting for the first time

this is coming from a fedora user, so probably check the docs (because i didnt lol)

cant distros entirely customise the welcome screen? i know fedora has distro specific lines on it which are different from KDE neon. and if they can do so, why didnt arch disable it altogether?

8

the welcome center already has a screen for discover that could perhaps be embellished with a short summary of native, flatpak and snap packages.

Screenshot20260513135146
Screenshot20260513135146786×738 48 KB

but too much here too fast will only ensure new users glaze over (that may already be the case, as i don’t know who actually reads these).

but once discover is launched and new users are searching for software, the focus should be on the native packages since that is what is encouraged to try first.

IF - there are other backends configured by the distro (snap and/or flatpak), then something to explain the sources drop down would be helpful.

but not all distros are going to have these backends installed by default, which would then require the user to know to search for “flatpak” or “snap” and install the backend support (an likely reboot).

that’s all a bit advanced for a new user just looking at the discover store.

perhaps the Home screen is a better place to introduce these other package forms with an Editor’s choice listing of the backend to install

—

now once backends are in place and the search results turn up not just native packages, but flatpak and/or snap alternatives as well, then you get into the sources drop down menu and the need for some “help page” info so the user can better understand their options.

it could list the advantages, and drawbacks of each form and even mention the need for the backends again, in case the user missed it the first time (or the only have one of them).

2 Likes
9

Yeah, this highlights the issue with the packaging mess on Linux…

For example native packages are encouraged, but OBS Studio or Bottles are great examples of applications that are packaged natively, but should absolutely not be used.

On the other hand you have distros like Fedora, that ship their own sort-of-kind-of-not-really Flatpaks, which often are broken or lack features, but still are called “Flatpak”.

I think we don’t need to overcomplicate - the original idea of a popup when hovering over the install button should be enough. Not too intrusive and coumbersome, but enough to sort of “hook in” the new user and get him interested if there are any other sources of software.

1 Like
10

Great examples that a not explained example is not useful. I am using native packages (Debian) and all is running fine. Where is the issue, if I do not need the latest features?

11

in the case of bottles, it’s far better/safer to run your windows software in a container than it to run them natively on your distro using wine.

as far as i know bottles is only available as a flatpak, but if you find a native package of it, i would not use it… use the flatpak instead.

1 Like
12

Was speaking about OBS, sorry for confusion.

13

Sorry, I was under the impression, that this blew up at a time so much, that it’s a known thing.

Bottles is officially released as Flatpak, as its built around the sandboxing and cannot properly function without it. Some distros (Fedora in particular) recompile Bottles and package as native packages, which are either non-functional, have severe bugs or may lead to massive security issues such as sandbox escaping if run non-sandboxed as native packages. This was a huge deal some time ago, Mirko (the lead behind Bottles) created an open letter to these distros, but got essentially laughed at and ignored. So there are native packages of Bottles that should not be used.

As for OBS - it is also oficially packaged as Flatpak and the native packages are recompiled and may in some cases lack certain codecs or plugins - for example, Fedora and openSUSE do not ship by default h.264 codecs, so using MP4 in native package is impossible, I know for a fact that there are a lot of bugs and problems in Ubuntu native package, that are solely introduced by it not being sandboxed and not having all the libraries it needs.

1 Like
14

Thanks for explanation. Many people are really new to Linux, so you cannot expect everyone is knowing this (and it is also not very present on internet search). In last half year Linux got round about 50% more Linux gamers (Steam hardware survey). Those information can be important for the next years.

Personally I am using *.mkv format for years, even before Linux and since OBS did not create any issue, I had no reason to search for the cause.