I am trying to understand which of the packaging and installation methods mentioned in the subject line is the most convenient from the perspective of a Linux end-user. I am searching for a simple solution similar to Windows' portable apps or Mac OS' application directories.
Which of the above mentioned packaging and deployment methods would you recommend?
A particular concern I have is the ready availability of packages for the software I need. Assuming that the most popular of those packaging methods are also the ones with the largest availability of packaged software, which direction would you point me towards?
Lastly, does any of those methods have a simple-to-use utility to convert (import) packages from other formats like .deb or .rpm? This would solve the issue of the limited availability of software, because almost all software is already available in those packages. With such a conversion utility I would do the repackaging myself.
Thanks.

My first remark is that you seem to be coming from windows. If you want money for it, and are not the best by a large margin, forget it. If your software is widely used, and you're doing a linux/MacOS version, read on.

As a Slackware64 user, I along with everyone security conscious would prefer source code with a list of required dependencies, and their dependencies. The preferred source should cater for at least these cpus. The linux kernel seems to cater for 2 dozen cpu architectures!

• x86_64
• X86_32 (possibly)
• MacOS (Intel Macs, not PPC or 68K)
• Arm64
• Arm (32) (possibly).

You will also need to get out reliance on windows only stuff (e.g m$ silverlight).

Debs or rpms are not at all easy to make. There's also a workload of updating regularly, but they get you into the bulk of distributions. The distributions will only maintain the stuff they want, and they might not pick yours. And they will want source code. But if you're maintaining the packages, they might list them as available.

The only one of your subject names I recognize is Appimage. I've seen three Appimages offered. All were big apps, more 'referenced' than written, hence they had piles of dependencies. I wouldn't run 2 together. I've seen None of the other package formats.

The other option is to pre-compile a self-contained subdir, e.g. http://www.slicer.org so all dependencies are contained in the one directory, paths adjusted accordingly, etc. These are options if your package is heavily dependent on others (Python modules, perl modules, java, DirectX, whatever) there may be conversion work to do.

I appreciate the reluctance to name your software, but you should at least categorise it.

1 members found this post helpful.

That's right

That's exactly what I had initially thought I would be doing, after moving to Linux. But then I soon found out that the "Linux way" is that each program has its files scattered all over the filesystem, in different directories (libraries, config files, etc). I am not at all criticizing this approach, only it is hard for me to wrap my head around it. What I would really like to have is self-contained directories, having sub-directories to contain all dependencies and config files. Again, I know this is not the Linux way because it defeats the purpose of shared libraries and thus is not efficient, but still. To me, the top priority is to know that an application is "safe" from system-wide changes that may break it, as it sometimes happens with system upgrades.
At least for SOME critical programs, this is well worth the effort.

After finding out that the idea of self-contained application directories goes against the Linux paradigm, I had initially abandoned the idea. But then one day just by chance I discovered that a program I had downloaded was working just out of the zip file, without the need to get it installed through a package manager. I copied it in a temp directory and it was working right away. Most significantly, that application was not contained in package prepared with any of the special methods mentioned in the subject line of this post, it was simply a zipped file containing the program and all of its required dependencies in subdirectories.
I was astonished and overjoyed that this was possible in Linux!!

However, due to my very limited technical skills, I did not know how to achieve this for any other applications.
All the software packages I download are meant to be installed through package managers, which scatter the relevant files all over the Linux filesystem.

The reason for writing my initial post was to find a way to create self contained directories. I had turned to the idea of using AppImages, FlatPaks, etc, just for this purpose.

But now that you mentioned that I can build an application on my own in such a way that all the dependencies are kept locally in a directory, without resorting to those methods, I realize that if indeed this is possible I would much prefer it.

Could someone suggest to me a simple way to create self-contained applications on my own, even if I have to download the source from Github and compile it?

I would be willing to spend time compiling every time a new version of the software is released, if only I could get a truly self-contained directory immune to system changes. I know this can be time consuming and highly inefficient, but it would give me peace of mind.

So, rephrasing and expanding on my question, can I MAKE self-contained directories for all applications? How to do this?
By any chance, does any of the popular package managers (pacman, apt-get, etc) have such a built-in option? Or is it something that I can only achieve by building from the source myself?

LOL, no reluctance at all, it's no secret. I was simply thinking of common applications that for me would be the most critical, such as email clients and word processors.

Thanks all,

Grabby

You can do everything you want by using the AppImage project's tools to wrap any software into an AppImage.

An AppImage essentially is a self-contained directory (an 'AppDir') including all dependencies which cannot be reasonably expected to be available on the user's system. However, this AppDir is compressed into a single file which at runtime gets mounted on a temporary mount-point for execution of its payload. The AppImage by default never needs to be un-compressed to run.

The AppImage project also has a tool to convert .deb packages into an AppImage ('pkg2appimage' command line tool). Popular misconception (and in parts hostile propaganda by supporters of competing package formats) often expresses wrong statements about "bloat" because AppImages frequently package specific versions of dependencies into the AppDir to make sure the AppImage works over a wide range of Linux distros. However, this additional "weight" is more than compensated by the internal compression of the AppImage. The AppImage of current LibreOffice 6.x typically consumes 200 MByte of your harddisk space as a single file, which you can place whereever you prefer (recommended is to create ${HOME}/AppImages, ${HOME}/Applications or ${HOME}/bin to keep all your AppImages at one easily to be remembered place.). The installed LibreOffice (whether RPM or DEB) typically occupies ~600 MByte on your harddisk, spreading all over your system with 6000 different files.

AppImages may be renamed to anything you like (no need to keep the .AppImage suffix), or symlinked to and they'll still run. AppImages can be integrated into your local system (so that they appear with their icons in the application menus, etc.). You also can have different versions of the same software as an AppImage and run them side by side if you want, without any conflicts...

If you like you can unpack an AppImage into a local self-contained directory (just run 'your.AppImage --appimage-extract') and can be run from there. This can be useful for debugging, or studying the inner working of an AppImage, but normally isn't needed at all.

The AppImage format gives you the widest-possible audience: it works even on those systems without any additional installations where their user would prefer to run Snaps or Flatpaks. Vice-versa this is never the case: if I as someone who prefers AppImages would like to run a software which is only offered as either a Snap or a Flatpak I'm required to install their respective runtimes beforehand. Much more trouble for me, much more inconvenience...

See also here for a comparison of features between Snap, Flatpak and AppImage: https://askubuntu.com/a/1009061/557827

Really: AppImage is what you want. It gives you most benefit for the buck, short-term. Forget about Snap and Flatpak, at least for now. Long-term, if you find flaws with AppImage which cannot be resolved, you can still have a closer look at Snap, Flatpak or Nix -- but this will be a multitude of effort for you as compared to AppImage.

1 members found this post helpful.

I forgot to mention: AppImages are designed to work 'immune to system changes' (at least as far as this goal can be achieved within reasonable limits).

You can run AppImages even from a USB thumb drive, or from a shared network folder.

Here is a list of ready-made AppImages, mostly provided by the original authors of the respective software. Their number currently stands at 665: https://appimage.github.io/apps/ and https://appimage.github.io/

1 members found this post helpful.

not sure if it was said already, but:

on linux, your first choice is always the distro's own package management system!
only if you cannot find a working application from there, should you consider one of the other choices.

@pdfkungfoo
Thanks for the very detailed and very useful reply.
From what you just told me, I probably have found what I was looking for. The utility pkg2appimage that you mentioned seems ideal for my needs, as it will enable me (a low-tech end user) to convert into AppImages any software I want, and then simply run it. (I still have to try but I take your word for it).
One more question: will config and data files also be included in the AppImage, or is it just the application itself? For instance, in the case of an email client, will the whole data archive be included into the AppImage?
Thanks

You may or may not know the following: all applications which write out and maintain their own settings (or your preferences), or which have a data archive to maintain (such as a mail client), or which by default store documents you create with them somewhere on your disk do so by typically doing this in a separate folder. This may be '~/Documents', '~/Photos', '~/Movies' or something similar for documents, or '~/.config', '~/.local', '~/.kde' or similar for settings/preferences.

While AppImages are very easy to use, they still offer "advanced" features. For example if you want to run different and bleeding edge versions of the same software side by side and concurrently (or in turn), this may lead to conflicting preference file formats as compared to the ancient version of the same software which you installed through the package manager. But this is not a problem of AppImages per se, it is a problem of the development of the packaged software itself, which for some (valid or stupid, doesn't matter) reason could not keep its config file format stable and unchanged. But well-built AppImages have a way to work around that problem: you can run them with one or both of the following parameters: '--appimage-portable-home' and '--appimage-portable-config' in order to assign their own private home or config folders, separate from the ones which your system packages use. This helps to not mess up your known and trusted configs and documents if you start to play with AppImages.

This is not the place to give a complete tutorial about all the features that come with AppImages. You'll have to study these by yourself. Go to https://github.com/AppImage/AppImageKit and find out where they currently host their user and their developer documentation. A quick start is to download a recently built AppImage, make it executable, and then run './your.AppImage --appimage-help'.

1 members found this post helpful.

There are now quite a few applications where the original developers provide pre-built binaries to their end-users in the shape of AppImages. You do not need to do it all on your own! You can find a list of more than 650 of them at the AppImageHub here, https://appimage.github.io/apps/.

Here are some of my personal favorites:

* Cura (3D printer slicing software): https://github.com/Ultimaker/Cura/releases
* Cutter (GUI frontend to radare2 reverse engineering framework): https://github.com/radareorg/cutter/releases
* GIFCurry (GIF maker from video sources): https://github.com/lettier/gifcurry/releases
* GitHubDesktop (GUI frontend for using GitHub): https://github.com/shiftkey/desktop/releases
* GVim (GUI for VIm): https://github.com/vim/vim-appimage/releases
* ImageMagick (CLI bitmap image processing toolkit): https://github.com/ImageMagick/ImageMagick/releases
* Inkscape (Vector editor): https://inkscape.org/de/~Moini/
* Kdenlive (Video editor): https://kdenlive.org/en/download/
* Kdevelop (Integrated Development Environment): https://www.kdevelop.org/download
* Krita (Painting program): https://binary-factory.kde.org/job/K...ppimage_Build/
* LeoCAD (Lego model CAD construction software): https://github.com/leozide/leocad/releases
* LibreOfficeStill (last released version, currently v6.1.x): https://www.libreoffice.org/download/appimage/
* LibreOfficeFresh (stable version with most recent features, currently v6.1.4): https://www.libreoffice.org/download/appimage/
* LibreOfficePreRelease (development version just before a potential release, currently v6.2.x): https://www.libreoffice.org/download/appimage/
* LibreOfficeDev (development version, nightly): https://www.libreoffice.org/download/appimage/
* LibrePCB (Schematics and PCB creation software): https://download.librepcb.org/releas...86_64.AppImage
* MuseScore (Music notation typesetting software): https://musescore.org/de/download
* NeoVim (VIm-like editor): https://github.com/neovim/neovim/releases
* Olive (Non-linear video editor): https://github.com/olive-editor/olive/releases
* OpenSCAD (3D model creation software): https://download.opensuse.org/reposi...age.mirrorlist
* QPDF (CLI tool and lib to process PDFs): https://github.com/qpdf/qpdf/releases
* Scribus (Desktop Publishing softare): http://impagina.org/download
* SubSurface (Linus Torvald's dive logging app): https://github.com/Subsurface-divelo...rface/releases
* SynfigStudio (2D animation software): https://github.com/synfig/synfig/releases
* TexStudio (LaTeX development environment): https://github.com/texstudio-org/texstudio/releases
* Trinity Desktop (Desktop wallet for IOTA crypto currency): https://github.com/iotaledger/trinity-wallet/releases
* VidCutter (FFMPEG-based video cutting software): https://github.com/ozmartian/vidcutter/releases
* Wire (Secure + encrypted collaboration + chatting platform): https://github.com/wireapp/wire-desktop/releases

Some of the developers provide AppImages only (and now RPM or DEB or else binaries) because they can cover most current Linux distributions with one single package format. They also do not have to wait for the typical delay (which can span between days, weeks, months or even years) which the distro packagers' work inject into the overall process before they can see the product of their blood, sweat and tears to be in the hands of their users. For a developer to build an AppImage removes any intermediary agency which stands in between their source code and the applications being used by end-users.

1 members found this post helpful.

The linux way of doing source isn't that hard, or that bad. https://linuxtechlab.com/reference-g...ory-structure/ Every system has compilers, a linker, and basic system tools for patching & debugging. Packages like imake and autoconf, and even my (and many people's) pet hate, cmake all generate necessary files from templates.

So your packages default to /usr/local, but you can put things just anywhere. Then there's environment variables that control search patterns. I'll mention 2: $PATH is like the path statement in autoexec.bat; $LD_LIBRARY_PATH tells the system where to find libraries. Everything is well documented. Library APIs (Application Programmer Interfaces) are commonly available. These days, most of the share (=docs, & misc stuff) and include (=headers for compiling against) is dumped in /usr/share, & /usr/include, and config stuff in /etc.

If this is a string you do not want to add to your bow, you can subcontract your work to places like Turkey, India, China, or Poland and hire a linux programmer there to do it. But there are real jobs in linux development.

There is one further thing to add, seeing as nobody mentioned it.
Wine (= wine Is Not an Emulator) is a linux program that takes Windows programs and runs them under linux by transferring windows system calls to linux ones. So it's fast by standards, and easy on memory. What's more, you can open two or three instances of the same program under wine, because it's a server/client relationship.
I have a Bible Encyclopedia under wine, and I can look up a passage, and in another instance have an ancient map or encyclopedia reference on the passage. Very handy. It also emulates all 32-bit versions of windows. Unless your code is teetotally 64 bit, though, you need a multilib install of linux with 32 & 64 bit libs. Not every distro of linux provides 32 & 64 bit libraries. You also need wine covering 32 & 64 bit code.