Is possible use install packages from others distros ?

[aug7744]

I am new to Linux.
I see that softwares installs use file extension DEB, RPM, APPImage and others.
Each package type is for each distro or is possible to use all in Ubuntu ?
I see also that is all number of packages for Ubuntu that means that has more softwares for Ubuntu than others distro ?
Thanks for replay.

[Paddy Landau]

First

There is a newish system known as snap, and a competitor known as flatpak. Where possible, I'd recommend that you use snaps (preferred by Ubuntu) or flatpak. For example, GIMP, LibreOffice and Zoom are all available as snaps, and DropBox as a flatpak. Snaps and flatpak are generally reliable, as they eliminate the dependency problems that you get from DEB installations, and you don't have to faff about with finding and adding PPAs.

EDIT: It seems that an appimage is a competitor to snaps and flatpaks, but I've never used one.

Second

Where an app isn't available through a snap or flatpak, you can use RPM with alien. Alien converts RPM and a few of others to DEB.

1. Install alien (either through your Software Manager or with this command (unfortunately not available in a snap or flatpak):
   

   sudo apt install alien

2. Convert your downloaded RPM package to DEB with the following command (change "package" to the name of the package that you downloaded):
   

   alien package.rpm

It's rare indeed that you need to worry about doing this, because when there's an RPM, there's almost always a DEB.

[TheFu]

Yes, but it is not a good idea.

Additionally, it is a bad idea for someone new to Linux who doesn't fully understand AND have a few years experience working with APT and dependency hell. You shouldn't do this. Do not install RPMs. There are some tools which will do this, but it is a bad idea.

Now, you can use flatpak, snaps, and AppImages. Those are supposed to be distro agnostic. Turns out they aren't, but at least they won't screw your APT dependencies up and trash the APT DB for every program on the system. Those self-contained packages are supposed to include all required dependencies too - turns out they don't always. I've had terrible luck with snaps where only 20% actually work. But when they don't work, just use snap remove.

• Snaps really don't allow any control for local needs due to upstream constraints. Also, snaps update without asking just like Win10 does. How rude!
• Flatpaks are better, in that we can locally control the constraints or disable them.
• AppImages don't have any constraints. Sadly, they won't work by using a symbolic link to the file, but that's a minor inconvenience really.

All three of these solutions are extremely bloated in both disk and RAM use, have slow startups or worse, make booting your Ubuntu system slow.
I avoid all of them whenever possible and seek out a trusted PPA.

Of course, it is your system and you should be free to use it as you like. Please have a backup ready BEFORE you install any RPM or random .DEB files. Things will probably be fine for a week or a month, but then the dependency issues will start and get drastically worse over time. By 3-6 months in, you won't be able to patch the OS at all, so reinstalling fresh will be the only option.

If you need a newer version of some program than what the Canonical repos provide, use a trusted PPA or snap or appimage or flatpak. The PPA method extends the OS APT repo to include that PPA. Which means if the PPA owner isn't trusted, she might do all sorts of nasty things to your setup. But PPAs for specific projects run by the project are minimal risk. After all, those projects created the .deb file which Canonical adds to their repos, so what's the difference? OTOH, anyone - you, me, someone not very nice, can also create a PPA and modify some code in the programs. Sometimes those modifications are exactly what we want and sometimes those modification include extras we don't - perhaps a crypto-miner.

[Paddy Landau]

… flatpak, snaps, and AppImages. Those are supposed to be distro agnostic. Turns out they aren't…

I didn't know that! I've been using snaps and flatpak for only a relatively short while, and so far I've had good results. On the other hand, I've been sticking to reputable apps such as GIMP and LibreOffice. Are you able to give an example of a problematic app (for my never-ending curiosity)?

… Please have a backup ready BEFORE you install any RPM or random .DEB files. … PPAs for specific projects run by the project are minimal risk…

Excellent points! I've stuck to PPAs from reputable projects, and for that reason I've hardly had problems. Even so, projects such as LibreOffice have given me the occasional problem while using their PPA, but not (so far) with its snap.

[TheFu]

VidCutter is one. If I try to run it over X11 from a remote system, it fails, badly. If I run it on the local system, it works. The AppImage works both locally and over X11, so it is definitely a snap failure.

Chromium is another. Same problem.

$ ssh -X regulus chromium-browser &
[1] 27705
X11 connection rejected because of wrong authentication.
[74721:74721:0718/095621.819118:ERROR:browser_main_loop.cc(1469)] Unable to open X display.

[1]+  Exit 1                  ssh -X regulus chromium-browser

But if I run any non-snap over ssh -X, they work as expected. It is a failure of snaps.

$ ssh -X regulus xterm -sb &

works perfectly. There have been many more, but when they fail, I remove them and seek out a different solution.

Snaps have all sorts of well-known problems that have been discussed in these forums to the point of ranting. I really recommend seeking those other threads out before you are burned by a snap refusing to work in a way you need - and you will be burned. Everyone will be, they just haven't hit a limitation yet.

BTW, your post above has lots of great information in it. I only worry that in this situation, your skills will understate what someone new to linux would need to know if/when things go south using an RPM. I've been able to avoid APT-hell the last 10 yrs. Around 2000, I did get a home RH server into RPM hell. Eventually, it was part of a reason that machine got hacked.

[TheFu]

Ouch - looks like the snap not working under remote X11 can be solved:

$SNAP_USER_DATA/.Xauthority, which of course did not exist. I then ran: $ ln -s ~/.Xauthority ~/snap/brave/current/.Xauthority, tried again and it worked.

https://forum.snapcraft.io/t/x11-for...using-ssh/2381

The fix of

export XAUTHORITY=/home/thefu/.Xauthority

didn't work. but on the remote system where I want the program to run from,

cd ~/snap/chromium/current
ln -s ~/.Xauthority

did work. I'll need to add that to my ever-growing, how-to-hack snaps so they work file. Maybe that will get vidcutter working too? I often run programs on remote systems and have them display locally.

[Paddy Landau]

Thanks for all of that information, @TheFu.

I'm brand new to Appimages. Looking at them, I see two problems:

• I don't find many of my preferred apps (as far as I can tell, there's a single list of them).
• They don't auto-update. I know that you don't like it, but for "average" users, auto-update is immensely useful.

I see also that is all number of packages for Ubuntu that means that has more softwares for Ubuntu than others distro ?

I forgot to answer this question.

DEB packages are those that work on any Debian system (hence the name "deb"). Those DEB files aren't made for Ubuntu; they are made for Debian.

However, any system that runs Debian, which includes Ubuntu and Ubuntu-based packages (there are many others), can therefore use DEB files.

Debian itself, and Debian systems, are highly popular (partly thanks to Ubuntu), which is why it's so well supported.

[TheFu]

Not all .deb files are created equal.

While they include some dependency lists, then don't include all, so it is really easy to find a .deb file from 10 yrs ago, download it and attempt to install it. If the user uses sudo dpkg -i /path/to.file-versions.deb it will be installed, but without the dependencies. Ok, so there's a fix for that - run sudo apt install -f and apt will try to resolve the dependencies and install them. But those dependencies are for an old Debian release from 10 yrs ago. All the core libraries have been updated since then, so either the system has a package installed which doesn't work or, worse, apt "fixes" the dependency problems and replaces the current versions of those packages with 10 yr old ones. 1 program works, but 1000 others do not. Now the entire OS is in "APT hell", because until the /path/to.file-versions.deb package gets removed, the dependencies will be screwed. When we install a .deb file, it is very important to keep track of it, so when APT starts complaining in a month or 3 or 6, we can go through the list and remove those packages to fix APT's dependency problem. Without that list, it is next to impossible to get out of APT-Hell short of doing a fresh install .... or restoring from a backup BEFORE the .deb file was installed.

I put the warning first. Some .deb files ARE fine. They were built for the specific release with the same core libraries as Ubuntu and the dependencies don't conflict with that Ubuntu release.

Anyone who's run any Linux OS knows about these dependency issues or learns about them quickly. All the distros have this same issue. Arch, Redhat, Fedora, Ubuntu-whatever, Oracle, Debian, Mint, PopOS, and the other 500 distros. We all have the same problem. But when we choose to run a fully supported LTS version of Ubuntu, pretty much all desktop applications will target our release so it is safer.

Snaps, flatpaks, appimages were created in hope of preventing these dependency issues AND making a universal way to distribute software across the different distros. Let's be honest, if you run Ubuntu 18.04 or 20.04, snaps have probably all been tested on those systems and should pretty much always work. OTOH, I still run the supported 16.04.6 release. It meets most of my needs AND gets fewer patches since all the code has been around 4.5 yrs now. But sometime before next April, I'll have to move all those machines off 16.04 to either 18.04 or 20.04 to keep security updates without hassle or paid support.

If any .deb file can install AND work onto any debian-based distro, then there wouldn't be a need for snaps, flatpaks, appimages. Alas, there is the theory and then there is reality. Reality screws up all sorts of things, right - except a freshly changed by someone else baby giggling. That reality is pretty awesome. Sometimes Ubuntu is like that giggling baby - all is right in the world. Then sometimes it is like a 2 yr old who learned "no" or a teen who hates her parents and says so, loudly, often. But eventually, we get a 30 yr old Ubuntu (16.04) which has moved out and thinks we were brilliant parents.










er. Perhaps not.

[SeijiSensei]

I doubt you'll need a package that exists as an RPM but not as a DEB. Most every open-source application is ported to all the various distributions. If there's something you need that doesn't reside in an Ubuntu repository, let us know, and we'll see if we can help.

Right now the only programs I know of that exist as RPMs but not as DEBs are those that use OpenSSL. Ubuntu is based on Debian, which has especially strict licensing rules, and its developers have a problem with the OpenSSL license.

[aug7744]

Unhappily I see that the diversification is killing the Linux because has peoples waiting to known that system and has several distros thus being very difficult to choice and also that problem with packages.
I had tried to known Slackware, but is full of commands and not is better to go it.
I am an advanced Windows user and that problem doing the system more slow when installing much softwares also is in Windows. Several duplicates files spread in folders and softwares allways starting with the system making more slow and less RAM available.
I will download Lubuntu to test and see my experience.
Unhappily I need some Windows softwares that not has in Linux, but if is possible WINE or other software run each Windows software without problems I not will return to Windows.
Another detail that I see is has games, emulators and others types that not is in Linux because exactly of diversification of several distros that does more work and the programmer coder not wait it. Is much work to create and update.

REPLY EDITED BY MODERATOR because I say my "good" experience with other OS. Not offense or bad level words. Nothing of create war between users.