Wording

[probonopd]

Please avoid the word "install" in conjunction with AppImages. The point of the AppImage format is that an AppImage does not have to be installed in the traditional sense, only downloaded (and made executable, although appimaged can handle that and, in the future, signature verification automatically).

So if possible please replace the word "install" with "download".

[simoniz0r]

I use the word install to make it clear that the AppImages will be ready to run after spm is done downloading them, chmod a+xing them and moving them to /usr/local/bin. In my opinion, it would not be clear to the users that the AppImages are fully usable after spm is done dealing with them if I just use the word download.

[probonopd]

There is no need to move them to /usr/local/bin. In fact, this is not recommended for most users as it requires root rights, something that AppImages generally do not need (unless you really want to make them available for more than the currently running user).

[simoniz0r]

I do this so that AppImages that are managed by spm will act just like a package that they install through their package manager would act in most respects. I think it's a good idea to show that AppImages can easily be a full replacement for some packages that aren't in a distro's repos or are out of date in the distro's repos.

[probonopd]

Well... we seem to have a different viewpoint on this. I think traditional package managers are way too limited: They enforce packages to be installed into the system, which needs root rights, they enforce a fixed location in the filesystem (usually /usr), they allow only for one version to be available at any point in time, and so on. AppImage has been designed in a way that does not have these limitations. So it would not be ideal if spm would re-introduce these old limitations of traditional package managers on top of AppImage, which was meant to do away with them...

For example, I want to store my AppImages on, say, a nework share. And I want to have 5 different versions of LibreOffice in parallel. I have no root rights. What do I do?

[simoniz0r]

The "limitations" of traditional package managers are a huge part of what I love about Linux. Everything has a place where it should go. Packages installed by the package manager usually go in /usr/share and have their binaries put in /usr/bin. Packages installed by third party package managers put their binaries in /usr/local/bin.

By following these standards, users are able to have a pretty good idea of how their package manager handles installing packages. I personally hate the way that Windows applications can go pretty much where ever they chose; it makes finding the installed applications a nightmare sometimes.

If a user wants to download AppImages themselves and place them wherever they want, that's completely up to them, but in my opinion, package managers should try to follow the standards that have already been established by other package managers. This keeps Linux organized in a sane, easy to follow manner.

[probonopd]

What is is about AppImages that you find worth supporting then? I mean, traditional distributions are pretty good at tradidional package managing... and Debian, in particular, is very strict about enforcing systematic rules. If that is what you are looking for, why not use that instead of AppImages?

AppImages are really more like .app applications in .dmg disk images on macOS.

[simoniz0r]

Ease of use, portability, extremely easy to create, they just work, and a few other reasons. As someone who does a bit of messing around with learning programming in my spare time, I had no plans what-so-ever of creating package builds for any distros as that would just be less time I could spend learning and creating things. When I found AppImages and found out how easy they are to use and build, I felt like I had finally found something that would allow me to easily package my simple apps and have that package work everywhere.

My goal with spm is to be a distro agnostic package manager that provides relatively simple applications that will work easily on any distro. I'd like for spm to be able to fill the gap that is left by many distro's repos when it comes to software availability and new versions of software.

Ubuntu has one of the largest repos out there, but I still find myself missing software or have out of date software that I either have to install manually with a deb, extract a tar and hope it works, or compile it from source. With AppImages, I can easily find and use software that isn't in Ubuntu's repos or is pretty out of date in Ubuntu's repos without having any effect on the base system. This, in my opinion, is much, much nicer than dealing with PPAs for a bunch of simple programs that I I want to install or are out of date.

For example, I just now ran into this issue when trying to upgrade the version of Audacious that I have installed through a PPA:

4 packages can be upgraded. Run 'apt list --upgradable' to see them.
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Entering ResolveByKeep 10%
  Dependencies are not satisfied for libaudcore5 [ amd64 ] < none -> 3.9-3~webupd8~xenial0 > ( libs )
Keeping package libaudcore5:amd64
  Dependencies are not satisfied for libaudtag3 [ amd64 ] < 3.9-1~webupd8~xenial0 -> 3.9-3~webupd8~xenial0 > ( libs )
Keeping package libaudtag3:amd64
  Dependencies are not satisfied for libaudqt2 [ amd64 ] < none -> 3.9-3~webupd8~xenial0 > ( libs )
Keeping package libaudqt2:amd64
  Dependencies are not satisfied for libaudgui5 [ amd64 ] < none -> 3.9-3~webupd8~xenial0 > ( libs )
Keeping package libaudgui5:amd64
  Dependencies are not satisfied for audacious [ amd64 ] < 3.9-1~webupd8~xenial0 -> 3.9-3~webupd8~xenial0 > ( sound )
Keeping package audacious:amd64
  Dependencies are not satisfied for audacious-plugins [ amd64 ] < 3.9-1~webupd8~xenial0 -> 3.9-3~webupd8~xenial0 > ( sound )
Keeping package audacious-plugins:amd64
Calculating upgrade... Done
The following packages have been kept back:
  audacious audacious-plugins libaudtag3

AppImages are perfect for spm's goal. As long as they are built correctly, they will just work on any Linux distro that is the same architecture as the AppImage was built for.

Linus Torvalds did a pretty good job of explaining what's wrong with the way that applications are packaged and distributed here. The problems he describes there are a huge part of why I've decided to create spm and also why I feel like AppImages are a perfect fit for having packages be easily distributed to any distro.

[probonopd]

When I found AppImages and found out how easy they are to use and build, I felt like I had finally found something that would allow me to easily package my simple apps and have that package work everywhere.

Yes, it's developers like you that I had in mind back when I started the project (and users like me without a root account on the machine, and/or only using Live ISOs for all of my daily work. In fact, I am typing this on a Live ISO... that starts entirely "from scratch" when rebooted, i.e., is "stateless").

Looks like the only thing we differ about is that you think that traditional package managers (and the limitations they enforce) are a good thing, whereas I just want to have each app in a file that I can "manage" (download, copy on a USB drive, share over the network, and delete) directly using a file manager in exactly the way I want (for example, storing downloaded AppImages in /usr would be entirely pointless on my machine since /usr is wiped clean to Live ISO state at each reboot of my machines),

[simoniz0r]

It's cool that AppImages are able to work well for you in that use case, but that's an extremely niche use case. The vast majority of Linux users not only use their package managers to install software to the standard directories, but they also prefer Linux to work this way.

[probonopd]

Still, an AppImage does not need to be installed, nor should it.

[simoniz0r]

I'm just using the word install to avoid confusion here and to stay in line with the wording I use in the rest of spm's functions. People more than likely aren't going to think that the AppImages are ready to use if I just say that they're downloaded. Hell, a large percent of people that ask about spm don't even know what an AppImage is. If I just say that the AppImages are downloaded, those people are probably going to be even more confused.

No, they're not installed in the traditional sense, but spm is installing them to a location where the user can just use them as they would any other package that they have installed.