Article proposal: Install and run .deb packages using toolbox.
[I don’t know if it is the right title]
Some software are distributed as .deb packages only. They are not in the Fedora Linux repository or other third party ones. And upstream doesn’t provide an RPM in their downloads page.
Sometimes you could install them from source. But sometimes they are proprietary software, and upstream doesn’t provide any other method to install them (no multi distro shell scripts, no Flatpaks and so on). Usually, the only supported Linux distribution for these software is Ubuntu.
For a long time we have a software called Alien, that can convert the DEB package to an RPM, but although the conversion usually works, the software usually fails to start due to lack of libraries, unavailable library versions, and so on.
In any case, compiling from source (if it is available) or using Alien, you could incur in a great waste of time ending with a fail. Not counting the mess you can generate on your system (broken dependencies, installation of packages that you will never use, untracked files scattered all around the system directories).
Cisco Packet Tracer (proprietary software) is distributed only as a DEB package. In the download page the only Linux distribution they support is Ubuntu 20.04
You could always fire up a virtual machine, install Ubuntu, and use the software in there. But sometimes people could have computers without all the resources needed to run a VM. In addition, if you need to use files in your host machine, you should find a way to share these files with the VM, and it is not always trivial for most users. A VM could be an unpractical way to run a single software.
As an alternative, you could try to use Toolbox.
It is still a work in progress, but with Toolbox you can use distributions other than Fedora Linux.
Let’s see how to do it. Let’s install and use Cisco Packet Tracer on Fedora Linux [Or it is too specific?]
Clone GitHub - Jmennius/toolbox: Unprivileged development environment
Build an Ubuntu 20.04 container image
[…] various commands here
Create an desktop file appears in the applications menu [How is it called in GNOME? Applications overview?]
The desktop icon will invoke toolbox
I’m not that familiar with the container technologies. But it sounds like a workaround to building a flatpak. Would it be better to package it as a flatpak? Then it could optionally be hosted in an online repository somewhere and updates could be distributed?
I’ve seen lots of complaints about toolbox breaking in various ways and I wonder if running Ubuntu containers in it might be pushing the limits a bit. I’m a little queasy about recommending something to people if it might be too fragile.
It is a workaround, but: with Podman you can run containers based on other distributions.
Toolbox breaking in various ways? Well, we have some articles about Toolbox, and it is a core part of Fedora Silverblue.
But it is out of the scope. I want to use a software that is distributed only as a .deb package. I don’t want to become a packager or to learn how to build a flatpak.
So, what alternatives do I have?
I mean, from the point of view of a simple user, what is the alternative if the software is available only as a DEB package? In various places (forums, chats) I’ve always seen people suggesting to try to use Alien or to manually unpack the .deb file and place the content all around the filesystem. And these are very fragile solutions too (if not worse).
However I agree that the Magazine is not the right place for tricks and workarounds.
If someone who better understands the inner workings of toolbox could give a better estimate of how likely such a workaround is to actually work in the general case and that estimate is better than say 90%, then I might be willing to give this idea the OK to run on Fedora Magazine. If it is more likely to result in failure in the general case, then I think we shouldn’t recommend this to people and we should tell them to run Debian in a VM instead.
This is just my opinion. If there are a lot of people who really want to do this, then I could be persuaded.
I use toolbox, and I think what @alciregi is wanting to post here is both appropriate and applicable to use of toolbox by an user who just wants to try out said Debian based package. I don’t think it’s a stretch to build said package from source in a toolbox.
In that case though, they appear to be making the toolbox container itself kali-based rather than running a container in a container. Am I misinterpreting what is being done? Which method is more likely to result in a stable system? The Kali Linux example appears to be based on a pre-built Kali Linux podman container from an upstream repository rather than something that is cobbled together from scratch. Basing the toolbox image on an official upstream container image seems like it might be at least a little more stable. Can something similar be done with your Ubuntu Linux idea?
Building from source would be fine. I don’t think that is what it being suggested though. I think the idea is to run Ubuntu in a container under a toolbox container and then install the .deb in that third-level OS image.
Mmm. No. Toolbox is not a container itself. It is a tool, a “wrapper” around Podman in order to simplify the use of pet containers. With Podman you can run any container from any repository or crafted by yourself. Toolbox at the moment is more oriented to run Fedora Linux containers. But you can run other distributions if the container images are suitable for how Toolbox works. And there are efforts in this way.
I mean, there is not a third level os. Images you can run directly with Podman, can potentially be used with Toolbox. So in this case you use Toolbox to run an Ubuntu image instead of the “default” Fedora Linux one.
Well, that can be done too, with caveats, for instance I only know of Unbuntu 20.08 container image working in Toolbox. But from the POV of toolbx, which uses Podman, it can use pretty much any container image you may want, but I personally try to stick with quay and docker container registries. I thought the post author was suggesting running a .deb installation of some package in a toolbox container running the normal fedora image. Plus, toolbox runs a pretty sandboxed setup, the user home get’s mounted inside and it runs in the users namespace as far as the system is concerned.
The toolbox environment is based on an OCI image. On Fedora this is the fedora-toolbox image. This image is used to create a toolbox container that seamlessly integrates with the rest of the operating system …
Cisco Packet Tracer is a widely used network simulator used in Cisco Networking Academy courses. It is closed source, of course. In order to download it, you are supposed to sign up, free of charges, to www.netacad.com
If you are a Fedora Linux user enrolling one of these courses, you will find only Windows, macOS and Ubuntu installation packages.
Well, the general concept of the article might be OK. But I’m not sure about cisco packet tracer as a specific example. There is a FOSS packet tracer/analyzer in the Fedora repositories called wireshark. Because “advancing free software” is one of the Fedora Project’s main goals, promoting proprietary software when there is an open source alternative seems contrary to Fedora’s mission.
At a glance, the other examples you’ve provided appear to have Windows versions available. I wonder if they would all work under wine? If so, that may be the better way to go. Certainly for something like an ebook reader, it seems like wine would be sufficient.
Can you find something that doesn’t have a FOSS alternative that is available as RPM, that doesn’t have a Windows version that works under wine, and that would likely be of use to many of the Fedora Linux users who read Fedora Magazine?
So again, I’m not so concerned about a FOSS alternative since this article does talk about an issue real world users of Fedora Linux face. The reality is, if I could have done my entire career in an open sourced way I would have in a heart beat. I feel this is the same for any person who reaches for the alternative provided by FOSS software in order to escape the closed environment they are trapped in by the mere fact that IBM decided back in the 80’s to use msdos on their newly created smart terminal based on Intel’s 8xxx series CPU’s.
So I still today have a bifurcated computer usage requirement that doesn’t get satisfied by Wine (32 bit crap cluttering my 64 bit Distro), but does nearly get met by using containers creatively. In that workflow, toolbx became very valuable.
Finally, what the post author is proposing is no different than installing a flatpak from a third party repo.