How to install packages

[Nasty7]

This isn't just KDE neon, I think it is a general question but will ask it here just in case. I just installed KDE Neon and love it as I do all my KDE Installs. Haven't done much as I am a hoarder and have to many distros to maintain. I installed Libreoffice via downloading the .deb from Libreoffice site. I did read however that I could have installed it via Snap, and I guess Flatpak? I don't yet know the difference an which is best?

For instance, which one will add the PPA so I don't have to Update it myself? Though I guess that's not a big deal as that is what I do on Windoze anyhow. And certainly it may be better to do it myself, so...

[claydoh]

If you install a snap, or a flatpak, or via the normal repos and PPAs, you can update via Discover. It checks for all three places.
Otherwise, you have to update each type separately via the commandline

sudo apt update && sudo apt full-upgrade
sudo flatpak update
sudo snap update.

Debs manually downloaded and installed are usually NOT updated via apt or Discover, though a few do set up repos form automatic updates, such as Google Chrome.

Form PPAs, each PPA page has the command needed to add it properly so that it is updated with apt and Discover.


There really is no 'best' between snap or flatpak, though often Flatpak seems to have more up to date stuff, in the things I use.

As to browsing snaps and flatpaks, Discover does show these, if you have them enabled there. But you have to look at each entry for a particular program, at the bottom of the description to see if it says Snap or Flatpak. You can also browse the Snap store and flathub, each of these will list the command needed to install it.


https://www.linux.com/tutorials/how-...flatpak-linux/
https://tutorials.ubuntu.com/tutoria...c-snap-usage#0

Now, there will be those that will say not to use Discover, and for package management (which is completely different from Software management), it is not very useful for advanced usage. But it is fine for browsing GUI programs and updating.

[jlittle]

... I installed Libreoffice via downloading the .deb from Libreoffice site.

What was the reason to do that? Maybe the version that came with 18.04 was too old. The answer to that question might bear strongly on your later questions. Downloading and installing a .deb is sort of a Windows way of doing things, but can be appropriate.

If you add a ppa properly, and the ppa is kept up to date, the normal APT mechanisms will update from the ppa automatically. I'd only resort to snaps or flatpaks and the like if I'd run into dependency problems or version conflicts.

[GreyGeek]

LibreOffice is also available as an AppImage.
https://www.libreoffice.org/download/appimage/
Once downloaded save it in a directory (I use ~/Downloads/AppImages) and set the execute permission.
Then, just click (or double click) on it and it runs. You don't need to have a daemon running in memory like you do for snap or flatpack. You can save your documents were you normally do. To remove it just delete the appimage. You documents stay where you put them (if you don't save them inside the appimage structure.). Many AppImages can be updated automatically.

I run 9 applications using appimages.

[claydoh]

As a note, Appimages are not updated by the system at all. They often have to be downloaded manually when you discover there is an update on your own, though some can update themselves, depending on how the creator has set them up.

[Nasty7]

Life has gotten complicated hasn't it!

@claydoh, thanks for the description! I see now that I could have installed it anyway I wanted. I wonder which is safest? I did read up a little after I installed LO, and there were some concerns for sure, as with everything I guess.
"As to browsing snaps and flatpaks, Discover does show these"
Yeah, I saw that after posting this, thanks again.

I wonder, do they run differently in any way? Will the .deb install be slower or faster running than the snap or flatpak? Do they both have the same functions and built as well as the .deb install? I guess I need to read up a bit more, and I have but was getting tired. I saw one good page that I'll link later that showed all the differences in all three packages, snap, flatpak, appimage.

Now I see some sites with instructions
How to Install LibreOffice 6.1 in Ubuntu 18.04, 16.04

@jlittle, neon don't come with LO, or much else for that matter.

@Thanks GreyGeek

All is well, and it was kinda fun installing the .deb version as it's been a while for me. But if I can install stuff via snap and flatpak I'll do that.

I just don't want to lose all my settings in LO, so that makes me wonder if Uninstall it later, when a new version comes out, can I keep my settings? As I remember there are options to do this in Synaptic Manager?

The Site Timed out on me and almost lost all that post above this!

[claydoh]

It all depends, to be honest. If a project, say Kdenlive, make a a flatpak themselves, you can likely assume that, as it has all its dependencies included, it should in theory be more stable than distro provided packaging, which may not have the exact specific versions that the flatpak has. You have to determine if you trust a source, or see the consensus of other users. Flatpak and snap have visible, viewable infrastructures as do distro packaging systems, so trust is easier to determine.
Appimages are more like windows exe files, a bit. You don't necessarily have the same trail, so in theory a bad actor could create a compromised file. Again, if you know or trust the source, it helps.


I do not find any particular package to be really 'faster', though that depends on one's system. On my slowpoke Celeron Chromebook, I can't really tell, They all load a touch slow all around. On newer systems, there may not be a y noticeable differences.

There is a potential for drive bloat as flatpak and snap both include built in dependencies, though each does break things into sub-packages, so one is not running multiple versions of the same set of libraries, so it is not too outrageous in terms of disk usage, but they do use more than the native deb packaging, usually.

[Don B. Cilly]

Personally, I hate snaps. See here for some reasons.

I also purge snapd from all my distros as even though there aren't any installed, it still slows down boot.
Try
systemd-analyze blame | head -n 20

[sithlord48]

I prefer distro made packages when possible and if I am going to install anything outside of my package manager I will use the AppImage if i can as it provides all the things needed to run the Application. You may not always get your system themes applied and you get to make your own menu entry if you care about that kind of stuff. But IMHO its better then the shadow systems provided by Flatpak or snaps. I purged snap on my kubuntu machines since it seams to prefer to install from snap.

[oshunluvr]

As far as the OP, installing the debs is in the LO read me:

sudo dpkg -i *.deb

[claydoh]

Neon is missing a core KDE component, Muon the package manager.
But it is in the repositories and thus easy to add to the otherwise frugal base install.

Snaps and Flatpacks contain libraries as available during packaging and it is totally depending on the packager whether they will be updated for security and other issues.

Muon is not a core KDE component at all, as it is distro-specific, or at least Debian packaging-specific.

[oshunluvr]

Muon is not a core KDE component at all, as it is distro-specific, or at least Debian packaging-specific.

...not to mention it rather sucks and is in need of some major reworking. Muon is horrible (but wasn't always) and Discover at first was really horrible. It's better now too, but still a long way to go.

[RANT]Honestly, if anyone in the Linux world cared about the average or new users, the TOP of the list of priorities would be the Installer (Ubiquity also has sucked for years, but is finally fairly usable. Still needs some features and improvements.) and the Package Manager. These are literally the most important parts of the user experience for new or low-interest users (those who just want it to work and don't care why). Why should developers care about new or low-interest users? Because a larger user base means more exposure. More exposure means more users. More users means more support from hardware makers and from software makers. Imagine a world where nvidia and AMD competed over each other to make the best video cards and drivers for Linux gamers. Then imagine the gaming software makers flocking to Linux because no more windows crap. Not long after that, and I mean real soon, all the hardware and software in the world would have a "Linux tested and certified" label on it and we could choose a product without checking first if it will even run at all. [/RANT]

[claydoh]

Yeah, the folks who develop such things are not the type that would actually use them.

Muon has been on life support for ages, unfortunately, after the creator moved on.
I like the concept of a software store (as opposed to package management) for general use.
I just realized that since I installed Neon circa 2016(?) I have not once used a graphical package manager, on any OS. Just Discover once in a while, and the command line. I used to fight like the devil to keep from becoming a terminal jockey.

Did I lose, or win?

[oshunluvr]

Yeah, the folks who develop such things are not the type that would actually use them.

Muon has been on life support for ages, unfortunately, after the creator moved on.
I like the concept of a software store (as opposed to package management) for general use.
I just realized that since I installed Neon circa 2016(?) I have not once used a graphical package manager, on any OS. Just Discover once in a while, and the command line. I used to fight like the devil to keep from becoming a terminal jockey.

Did I lose, or win?

Same here. In a perfect Linux world, the package manager would have both modes - "store" or "package list". I ended up using the CLI because I wanted both the input AND the output. I can see failures before they cause problems. Really, I can't recall a package manager doing that very well.