AppImages Snaps flatpaks CDE &c - General Information: NOT ABOUT SPECIFIC APPS

[mikeslr]

Please ONLY add to this thread other repositories; general information about AppImages, Snaps and Flatpaks, techniques for working with them and corrections of any mistakes in this thread,
To assist anyone looking for a particular application or type of application, please discuss specific applications under the Software Section discussing that specific type of application.

At its best, an AppImage is an application which is self-contained and fully portable. That is, it does not look to the operating system under which it is runs for any library or other dependency; and it can be run from anywhere: no need to install it.

The usefulness of such devices have been demonstrated by Frugal Puppy's employment of SFSes for a decade. And when they appeared even the first debiandog supported SQUASHFSes. Separate from the rest of the operating system, library conflicts resulting in failed or broken applications can be avoided: If an application has libraries which conflict with the libraries of another applications, just don't load them at the same time. When not loaded, SFSes/SQUASHFSes make no demands on RAM or CPUs.

Currently, at least in theory, Puppies and DebianDogs can make use of AppImages, Snaps and Flatpaks. These provide the above benefits, and more. When an SFS is loaded, its component files are distributed throughout your system; hence the possibility of library conflicts. AppImages, Snaps and Flatpaks only look within their own structure for libraries. This not only avoids conflicts between applications. Some libraries are required by the operating system, itself. Attempting to use a conflicting library even temporarily would result in operating system failure. Such conflicting libraries can be built into the AppImage, Snap or Flatpak.

Perhaps as important today with the thread of malware present whenever access to the internet is had, these methods of application deployment are sandboxed and not easily modifiable. Sandboxed means they do not interact with your system or other applications. To modify them, you have to unpack them, make changes and repack them. Any threat is at worst temporary: existing in RAM and wiped on shutdown.

Of the three, AppImages are the most useful for Puppies. To make use of Snaps and Flatpaks [except as a source to be unpacked and rebuilt] requires that the applications to access their repositories be installed. Many AppImages, on the other hand, can be used OOTB. In fact, hopefully fredx181's utility for creating a 'simplified' AppImage will soon be available on this Forum.

Unlike SFSes/SQUASHFSes, AppImages at not linked to the operating system thru /mnt. Rather, they link thru /tmp. The contents of /tmp are not preserved in SaveFiles/Folders on shutdown/reboot. This may pose present a challenge if you wanted to use an application in AppImage format as your default application for its type of work. It isn't difficult to provide a menu entry or launcher. A bash-script "on the path" could call it and can be used in Rox's right-click menu. But assigning mime-types to it so that Left-clicking a datafile would open the Application-AppImage is something 'above my paygrade'.

Not all AppImages will work OOTB. Some never will. They are built and tested under "Big-Boy distros". Puppies may not include some libraries which the builders assumed would be present. It is possible to unpack an AppImage, include missing libs and repack them. But, especially when the missing library are Qts or Qt5s, it is easier to install those libraries into Puppies so that they will be present not merely for a particular AppImage, but for any application which needs them.

Some AppImages refuse to run 'as Root'. Mike Walsh showed that those could be opened via a wrapper.

https://appimage.github.io/apps/ is a source for many AppImages.
Edit: per bigpup @viewtopic.php?p=14706#p14706
"Slightly different link to the one on the first post above.
https://appimage.github.io/.
AppImageHub main web page divided into sections and having visual images of each appimage."
Another entry-point providing categorized links to AppImages. https://www.appimagehub.com/. Thanks, bark-woof-fetch, for calling it to our attention.

[mikeslr]

Link to thread on which there are many links to AppImage Sources and Discussions. https://forum.puppylinux.com/viewtopic.php?f=4&t=383

[fredx181]

That is, it does not look to the operating system under which it is runs for any library or other dependency;
....
AppImages, Snaps and Flatpaks only look within their own structure for libraries.

Don't know about Snaps and Flatpaks, but for Appimages I think that's not correct, it does look for other (than included in the Appimage) in the system.

Not all AppImages will work OOTB. Some never will. They are built and tested under "Big-Boy distros". Puppies may not include some libraries which the builders assumed would be present. It is possible to unpack an AppImage, include missing libs and repack them. But, especially when the missing library are Qts or Qt5s, it is easier to install those libraries into Puppies so that they will be present not merely for a particular AppImage, but for any application which needs them.

I may not understand well, but doesn't this contradict the first quoted sentences ?
Sometimes an appimage won't run because of a missing dependency, then installing it in the system can solve it.
Often it's expected that most important binaries and libraries are already installed in the system (e.g. gtk), so can be used by the appimage.


Fred

[nic007]

Not quite on topic but - The basic released Puppy distributions use the same applications distribution after distribution and of course all of them works out of the box. We really only have problems with software other than the standard Puppy "normals", eg. VLC which is not standard issue in most distributions but is used by many Puppyists. As long as we have dedicated people who will compile these other commonly used applications for a specific distribution, everything should be fine for the "basic" Puppy user.

[wanderer]

i am just a user
so my understanding of this is limited
but

i think fredx portable firefox is the perfect example
it requires no manager system be installed like flatpack etc
doesn't interfere with the libraries already loaded
and upgrades automatically

i put it in corepup so now i have a up to date firefox all the time

woof-ce has a mechanism to build packages against whatever libraries are used
so the base system is covered

but other ad hoc remasters do not

i am hoping that fredx will continue his work
since this is of great benefit to a lot of people

in addition how to build these systems in of great interest
how to resolve dependencies and paths etc

remember pupngo by goingnuts (base of 6 megs)
and corepup/tinycore (base of 9 megs)

could these types of very small base systems provide a simple known base for these packages ?

and what about slitaz ability to convert many different package formats into a common one
could that be used in process of creating packages

anyway all very interesting


wanderer

[wanderer]

hi guys

does anyone know of or could they make a portable vlc player

wanderer

[fredx181]

hi guys

does anyone know of or could they make a portable vlc player

wanderer

Member watchdog made a few, see http://murga-linux.com/puppy/viewtopic. ... 87#1033887 (vlc-3.0.7.1-i386-portable) and more directly on the next page, don't know if they work well.

Fred

[wanderer]

thanks fredx

i will try them

using your busterdog now
its awesome
no problems

wanderer

[wanderer]

hi fredx and all

alas the vlc portable segfaulted

is there any information around
of how to go about building a portable vlc app
or something like your portable firefox directory


thanks

wanderer

[darry19662018]

Wanders,

If you don't mind an older vlc there is this one I use on older systems like my remaster of Dpup Squeeze
https://sourceforge.net/projects/portab ... 1/download
simply make it executable.

[wanderer]

thanks darry

will try


wanderer

[wanderer]

hi all

does anyone have any information about how fredx builds his portable firefox

to me that is the preferred method

download and build script is nice

or

whole directory can be made into a tarball
download
untar
sudo chmod 777 -R
run start script

can look inside and modify
can write to the directory instead of system
can change symlinks in directory to write/read to/from other places outside directory

wanderer

[mikeslr]

First read the pkg-cli thread, http://murga-linux.com/puppy/viewtopic. ... d69#985531

Then follow rockedge's instructions, viewtopic.php?p=3651#p3651

Let us know what other Puppies rockedge's instructions work in; and what problems you encounter. Or better still, about problems and their resolution regarding specific applications and/or Puppies, perhaps just post a link to those discussions.

[wanderer]

hi mikeslr

i am assuming that your post is info for me

i will read the stuff and give things a try

i will move my attempt to the thread for vlc pets links etc
since i don't want to clog this thread

thanks much for pointing me in a direction

wanderer

[muggins]

avidemux_2.7.6.appImage works in Peebee's LxPup64.

[puppyuser2]

I haven't been able to run any new appimage for a long time on puppy linux. I get errors that suggest that I cannot run as root without --no-sandbox

The appimage file ar mad executable. Does anyone know how I can get appimages to load on my puppy os?

[mikeslr]

Hi puppyuser2,

"I haven't been able to run any new appimage for a long time on puppy linux. I get errors that suggest that I cannot run as root without --no-sandbox...Does anyone know how I can get appimages to load on my puppy os?"

I can think of two ways. But the second is a PITA rarely worth pursuing: Extract the AppImage and rebuild it.

MIke Walsh figured out the first: Start the AppImage via a wrapper. I think I first learned it from his thread about Leonflix which I've used as a Template. What he did was create a bash script (made executable) named Leonflix-launch. On my system, the contents of that script are:

#!/bin/sh
#
# Start 'Leonflix' AppImage
#
/mnt/home/Pup-Apps/Leonflix.AppImage --no-sandbox

Note, both the name of the AppImage and the path to it must be exact: capitalization matters; but you can rename any AppImage. In the above it's possible that Leonflix's name originally included details about the glbc library or a version number. I could have named it "MovieSearch" and even left off the ".AppImage".

Also note, IIRC, it doesn't always work. But testing only takes a minute and I generally forget about transitory annoyances.

There might be a different work-around. Try running it via a wrapper using the 'run-as-spot' command. I think it would read something like:

#!/bin/sh
#
# Start 'Leonflix' AppImage
#
run-as-spot /mnt/home/Pup-Apps/Leonflix.AppImage

[bigpup]

Running Fossapup64 9.5

I put Appimage files in the /root/spot directory.
Navigate to this directory.
Click on the appimage and it runs.
Note:
Some do not have this set. Need exec permission to run.
Check the appimage file properties and make sure it has exec permissions.
If not, give it exec permissions.

I do a little more and make a appimages directory in spot directory.
Put the appimage's in it.

[bigpup]

Slightly different link to the one on the first post.
https://appimage.github.io/
AppImageHub main web page divided into sections and having visual images of each appimage.

[mikewalsh]

Running Fossapup64 9.5

I put Appimage files in the /root/spot directory.
Navigate to this directory.
Click on the appimage and it runs.
Note:
Some do not have this set. Need exec permission to run.
Check the appimage file properties and make sure it has exec permissions.
If not, give it exec permissions.

I do a little more and make a appimages directory in spot directory.
Put the appimage's in it.

That's OK if you have plenty of space, and don't mind having a fairly large save-file/folder to accommodate these things.

This is why I prefer to keep all mine in an externally-mounted directory instead, and use the wrapper scripts to launch them. Doing it this way, you can even keep all your AppImages on a flash drive.

I prefer to have everything starting via custom MenuEntries, but this can be problematic with flash drives, since they don't always mount to the same place in /mnt, thereby changing the $PATH. However, one way round this is to place each AppImage on the flash-drive inside its own sub-directory, put its 'wrapper-script' alongside it, and edit the script to point to the AppImage, e.g:-

Create a script, called 'LAUNCH' (or 'START', or 'FIRE IT UP'.....anything you like, really! )

Then:-

Code: Select all

#!/bin/sh
#
# Fire-up-your-AppImage
#
./name_of_AppImage

.....which works nicely, and permits keeping all your AppImages on a flash-drive you can carry around with you. The exec line can be modified:-

Code: Select all

./name_of_AppImage --no-sandbox

...or:-

Code: Select all

run-as-spot ./name_of_AppImage

....whatever is needed to get the thing running. All you do to start the AppImage is to click on the launch wrapper, instead.....and don't forget to make sure the AppImage has 'Exec' permissions!

(You can also use 'udev-rules' to ensure that any given flash-drive will always 'mount' to the exact same location every time.

http://murga-linux.com/puppy/viewtopic. ... 321b259228

If you go this route, permanent Menu entries are then a viable proposition.)

OR:- Having set your AppImages up in sub-directories with wrapper-scripts, you could create another sub-directory (say, "#1-MENU"), then sym-link all your wrapper-scripts into this and re-name them appropriately. This gives you a kind of 'Menu', with all the launchers in one location; using "#1-" in front of the directory name puts it at the beginning, a logical place for it.

Ideas, ideas, ideas.....

Just a few tips for y'all...

Mike.

[tosim]

For those of you who use appimages, this might be of use:
https://github.com/TheAssassin/appimagelint/

[gyrog]

I just did a little experiment,
I downloaded a .appimage file and saved it to an ext4 partition, set it's permissions to be executable, created a symbolic link in /root/my-applications/bin/ and I could execute it fine via just the name of the symbolic link.

Hmmm.., that's a bit boring.

But, having established that the .appimage will work under my Puppy,
I copied it to a fat32 partition, and setup another symbolic link, and lo, it also worked.
So it seems as though a .appimage file can be located on any filesystem, perhaps.
That could be useful, if you are running Puppy, all on a fat32 usb stick.

It's significant to me, because I had been thinking that the concept of having a program in a .sfs file and using it by mounting, executing, and immediately umounting it; might be worth exploring.
But, if a .appimage file can be exceuted directly, wherever it is, why go through the hassle of mounting/umounting a .sfs file?
The same goes for the idea of making a .sfs file available by creating a lot of symbolic links instead of adding it to the aufs stack.

[dancytron]

I just did a little experiment,
I downloaded a .appimage file and saved it to ann ext4 partition, set it's prermissions to be executable, created a symbolic link in /root/my-applications/bin/ and I could execute it fine via just the name of the symbolic link.

Hmmm.., that's a bit boring.

But, having established that the .appimage will work under my Puppy,
I copied it to a fat32 partition, and setup another symbolic link, and lo, it also worked.
So it seems as though a .appimage file can be located on any filesystem, perhaps.
That could be useful, if you are running Puppy, all on a fat32 usb stick.

It's significant to me, because I had been thinking that the concept of having a program in a .sfs file and using it by mounting, executing, and immediately umounting it; might be worth exploring.
But, if a .appimage file can be exceuted directly, wherever it is, why go through the hassle of mounting/umounting a .sfs file?
The same goes for the idea of making a .sfs file available by creating a lot of symbolic links instead of adding it to the aufs stack.

Way back in Lupu Lucid 5.28, RSH made a version of Puppy called Lazy Puppy that worked by downloading, mounting and unmounting sfs files on demand.

It worked great, but I think he created all the sfs files and scripts manually, which must have been a huge amount of work.

[gyrog]

but this can be problematic with flash drives, since they don't always mount to the same place in /mnt, thereby changing the $PATH.

Another way around this would be to use the command:

Code: Select all

blkid -U <UUID>

This will list the device name of the usb stick, if it is plugged in, and if <UUID> is the UUID of the usb stick, which does not change.

Edit:
To get the UUID of a device, plug it in and:

Code: Select all

blkid /dev/<name>

where <name> is the name of a partition, e.g. "sdc1". This will list a line of stuff including the UUID.

[dancytron]

Just a thinking out loud comment, but one way to manage AppImages with Puppy might be to have them in /opt by default, but then have a script that copies them to /mnt/home, sets new .desktop or shortcuts, and then does a "remaster" (or maybe "resquashing" would be more accurate) of the main .sfs file to reclaim the space.

So depending on how a person installed Puppy, they could have them in /opt in the main Puppy sfs file or on /mnt/home depending on what is more convenient.

Kind of like Lazy Puppy for appimages. Well not really, but that was what gave me the idea.

[mikeslr]

Actually, dancytron, locating AppImages in /opt is a very good idea if you intend to use nic07's nicos-utility-suite>Save2SFS to create a Puppy which doesn't use a SaveFile/Folder and so doesn't have to mount any partition.

Edit: Well, that probably won't work. Just tried running an AppImage from a Puppy without a SaveFile/Folder and got the following message:

External-AppImage.png (14.93 KiB) Viewed 3569 times

But as noted in the screenshot, AppImages can be extracted. The extracted folder could be located in /opt and its executables linked to 'the path'. Might save some work involved in otherwise creating the application.

[gyrog]

I would have thought the logical use for things like ".AppImage" files would be a kind of replacement for standalone ".sfs" files, rather than in any Puppy system ".sfs". So while it's a good idea to have a "standard" place for these things for ease of integration, since these things can reside anywhere and still function, I would have thought something like '/mnt/home/portables/'.
If you use an actual ".AppImage", it inludes a ".sfs" within it.

To play with these things, I just produced a ".AppImage" of FrugalPup, viewtopic.php?p=27889#p27889.
The interesting thing about it is the "AppRun" script I found on the net, that enables the ".AppImage" to contain multiple utilities, as FrugalPup does. You just create a symbolic link to the ".AppImage" file for each of the utilities with the symbolic link having the internal name of the utility, and then the "AppRun" executes the appropriate internal binary based on the name of the symbolic link used to run the ".AppImage". e.g. For FrugalPup, there is a symbolic link for 'bootentry', 'diskpup', 'frugalpup', 'f2stickpup', and 'stickpup'.

[mikeslr]

Hi All,

Although the last few posts have been about easing the work-load by using already existent AppImages rather than such other package formats as SFSes, this seems a good place to note fredx181's "Create AppImage" application. You'll find its thread here, viewtopic.php?f=106&t=590.

And as I haven't had breakfast yet and my mind is wandering, just to note (a) fred's application not only can create portable AppImages, it can also create --with limitations-- applications that work in 'chroot mode'; [plus, as Mike Walsh noted, generate Rox-Apps as a byproduct]. And (b) Mike Walsh's post earlier in this thread about starting AppImages via wrappers, viewtopic.php?p=16465#p16465.

And lastly, I don't recall there having been much testing or discussion about the use of fred's application's 'chroot mode'. Seems there may be circumstances where it might be just what's needed. But at this point the train of thought gets derailed. So time to have breakfast.

[gyrog]

Although the last few posts have been about easing the work-load by using already existent AppImages rather than such other package formats as SFSes, this seems a good place to note fredx181's "Create AppImage" application. You'll find its thread here, viewtopic.php?f=106&t=590.

Thankyou for the link.
For the 1 appimage I've made, I just manually created the AppDir, and then ran 'appimagetool' to create it.
Now I know about fredx181's tool, I'll try it.

How do you all make appimage files?

[mikeslr]

Note the edit I made to this post. viewtopic.php?p=27831#p27831. I tried starting several AppImages I just downloaded from the Web and got the same "Cannot mount AppImage" notice or just no response. But then I tried two I made with Fred's application: gnewpet and veracrypt. Both opened from a location on a hard-drive once it was mounted. I then moved the veracrypt appimage into /opt and unmounted the hard-drive. Again it opened.
Don't know what the implications of the above are. For now, I can only suggest them to be an area worth exploring further.
Examining fredx181's original post, https://oldforum.puppylinux.com/viewtop ... 9#p1011814provides some insight:
"Advantage of an AppImage is that it is mounted in /tmp"... Several other statements in that post suggest it as 'required reading' for those undertaking further exploration.
For example, in my mind the statement" should contain all required dependencies" and that a 'rox-app' is generated as an intermediate step/bi-product seems to parallel the requirement for creating a portable-app using this code [taken from fred's launcher script for firefox portable sans its arguments relating to the creation/location of a profile]:
#LAUNCHDIR="$(cd "$(dirname "$0")"; pwd)"
LAUNCHDIR="$(dirname "$(readlink -f "$0")")"
...
LD_LIBRARY_PATH=$LAUNCHDIR/:$LAUNCHDIR /extralibs$>>*
{LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} "$LAUNCHDIR/firefox" "$@" ...

Even hazier, but with a strong feeling that it may be important --note the Off Topic thread questioning 'what if Puppy no longer existed'-- is how to duplicate Puppys' abilities if the one source of auf dried up? Isn't Puppys' modular nature, itself, --merging the Puppy_xxx_version.sfs with zdrv.sfs, fdrv.sfs, and any adrv.sfs and ydrv.sfs in RAM--- dependent on auf? I would expect, at a minimum, that application sfses could not be used.
Which is where gyrog's exploration and development of overlays comes in and may play a crucial role in Puppys' continuing existence. I know nothing about 'overlays' beyond that they exist. Overlays with AppImages and/or rox-apps? Indeed, about almost all the concepts I've mentioned I am viewing them as through a glass darkly.

=-=-=-=-=-
* the >> has been used as a symbol to show that in the original what appears here as two lines were, in fact, one continuous line. *, of course, is the commonly understood symbol designating 'see footnote'.