me, who definitely knows how to and in fact totally prefers to build everything from source: [nervous laughter] yeah what kinda dingus exclusively uses .debs amirite?
I don’t know what the Linux community’s consensus on appimages are, but I wouldn’t mind if people made more appimages because, for the few distros I’ve used, appimages just usually work.
AppImages are definitely convient to use. However the two issues I have with them are that there’s no easy way to find them (eg flathub) and they’re not automatically integrated with the DE. Requiring a tool that manages AppImages to make it easier.
Open it up in midnight commander, and it will unpack it into a virtual directory structure, complete with install/uninstall scripts.
Look at the install script to see what it’s thinking, pull out the file structure, copy into your filesystem.
Oh, and hope. Because often you need to get matching glibc and other dynamic libraries that the program was compiled against. Which isn’t the end of the world as the dynamic linker will look in the local directory where the program is first for libraries, but it becomes a hassle pretty quickly.
distrobox: Tool for creating one-off containers of a different Linux distro.
container: A virtual OS environment that runs on your computer, but doesn’t know that it’s running in your computer. It’s not the same as a VM or emulator.
flatpak: A tool designed by RedHat for running sandboxed Linux programs in any environment. Flatpak can either refer to the system as a whole (eg: “You need to install flatpak on your machine to use our tools”) or an individual program packaged for the flatpak system (eg: “You must download the latest flatpak of Firefox”).
AUR: The Arch User Repository. A collection of installation scripts to add software to Arch Linux. These scripts are not owned or maintained by anyone officially affiliated with Arch, so you can find AUR packages for almost anything.
So, the comment becomes: Stick it in a dedicated environment designed to run Debian. Then package it so anyone can run it. Then make it easy for anyone running Arch Linux to install it.
It’s just maintaining arch that was a bit of a headache for me. I loved having access to the AUR and being able to use bleeding edge… well, everything. But too much of my time ended up going to fixing issues after updates or finding out what package to choose when there were conflicts during updates.
Arch User Repository. If you’re using Arch, you get the basic stuff from the official repositories. But for most programs there’s the AUR. They’re often less polished, some of it may be proprietary. There are package managers dedicated for it, that also know to handle the official repositories. Read more
Hey, I see you tried to make this link: Read more, but you did it wrong. The exclamation mark (!) in front of a link is used for embedding media.
Tip: You can embed image into link to create a button
Stability, slow changes, predictable, strong history, lots of distributions are based on it, the list goes on and on. I don’t use it but it’s kinda stupid to question it’s relevant qualities considering how much it’s brought to the Linux community.
I’m on Gentoo for example. I can write an ebuild to automatically download said deb, extract it, install it with the package manager… And if the site has any semblance of organization involved, I can write one ebuild that will always download the version specified in its name, so when there is an update, I can copy the ebuild, change its name to new version and if the dependencies or structure didn’t change, it will install just fine without any work.
I am quite comfortable finding my way around ArchLinux, and recently decided to give Gentoo a try. I didn’t expect it to be that much harder but all the cflags, emerge, conflicts and updates feels like black magic. I guess that if you know your way around Gentoo, reverse-engineering a deb file is not a real challenge. However I’m assuming that most Linux users would hope for a less involved solution.
Add comment