Create Portable AppImage

[mikeslr]

Hi All,
EDIT 2020-12-24 new attachments and info at second post of this thread.

The following was originally posted by @mikeslr (thanks Mike ):

I didn't see a thread about fredx181's Create Portable AppImage (or selfextracting script), http://murga-linux.com/puppy/viewtopic. ... 14#1011814. @ rockedge: don't hesitate to move if there is one. Or email me and I'll do it.

Per that post:
"Options:
- 'PortableAppsLinux Mode' or 'Chroot mode' choice
The 'Chroot Mode' gives a better chance that the app will run (specially with complex apps)
But for simple apps, I'd recommend 'PortableAppsLinux Mode' (runs faster)
(see more info below)
- Create appimage from selected directory "AppDir", or
- Create appimage from selected .sfs or .squashfs (Chroot Mode only)
- Create selfextracting script instead of appimage (using makeself https://makeself.io/)"

I haven't used the Chroot mode. But the portable mode works well. I find it particularly useful when remastering if I want to strip out applications from the puppy_version_number.sfs and perhaps place them in an adrv/ydrv or SFS or even in a portable-appimage. There are a number of tools to facilitate this:
jpeps' gnewpet, http://murga-linux.com/puppy/viewtopic. ... 673#598673 will create a pet consisting of all necessary files of builtin or installed application;
Among others, taersh's PaDS, http://murga-linux.com/puppy/viewtopic. ... 922#998922 will combine pets and SFSes, debs and other packages into either a pet or an SFS, including Suites or adrvs/ydrvs;
and
shinobar's remasterX, http://murga-linux.com/puppy/viewtopic. ... 345#780345.
And, of course, there are other, similar applications.
However, what all these have in common is that they are part of your operating system when you remaster and become 'builtins' in your remaster. A portable-appimage created using fredx181's tool mounts thru /tmp; and applications linked thru the /tmp folder are not included in remasters.

Take a look at the screenshot at http://murga-linux.com/puppy/viewtopic. ... 14#1011814 and note where it has you "Select the directory to use as 'Appdir-root':" AFAIK, any source can serve as that directory. For example, UExtract a pet and use the folder within the extracted folder; or mount an SFS and copy its contents into a folder. "Patched" snaps and flatpaks --decompressed and patched to include libraries absent from Puppies-- can also be 'repackaged'.

Edit: I had included nicOS-Utility-Suite, viewtopic.php?p=1533#p1533 provides many tools including a couple different ones for remastering; but although an AppImage was created, it did not run the remaster module. Didn't try the others.

[fredx181]

Thanks Mike, I already had in mind opening a thread for this, here, but you saved me some work.

Attachments: create-portable32-v2.1.tar.gz and create-portable64-v2.1.tar.gz (just in case the old forum goes down again):
------------------------------------------------------------------------------------
EDIT 2020-12-23: Bug found when using .sfs or .squashfs as base for creating appimage, see info (and .deb packages):
viewtopic.php?p=13148#p13148
New attachments, v2.2 with fix included.
------------------------------------------------------------------------------------

Fred

[mikewalsh]

- Create self-extracting script instead of appimage (using makeself https://makeself.io/)"

Cheers for that link, Michael. I'd long suspected Nvidia's Linux driver .run files were a form of self-extracting script, and this has just confirmed it:-

"Examples of publicly available archives made using makeself are :

Game patches and installers for Id Software games like Quake 3 for Linux or Return To Castle Wolfenstein ;
All game patches released by Loki Software for the Linux version of popular games ;
The nVidia drivers for Linux
The installer for the Linux version of Google Earth
The VirtualBox installers for Linux
The Makeself distribution itself
and countless others…"

(Emphasis supplied).

So now ya know..!

I've had Fred's create-portable32 & create-portable64 scripts set up in their own, dedicated "work" directory for quite some time. They are immensely useful, and are how I created the portable BackSeatDriver packages.....because, as a 'by-product', they just happen to create a RoxApp, too.


T'other Mike.

[fredx181]

Bug fix, new attachments, create-portable appimages v2.2 here: viewtopic.php?p=3328#p3328
More info here: viewtopic.php?p=13148#p13148

Fred

[bigpup]

fredx181,

You really need to be the one to start this topic.
That gives you control of the first post.
Now, if you come up with something new, it is going to be down in the posts, because you can not edit the first post!

[rockedge]

@fredx181
You are now the author of the first post.
viewtopic.php?p=3250#p3250

[fredx181]

Thanks @bigpup and @rockedge
Edited first post a little.

Fred

[HerrBert]

Is it just me having trouble with create-portable64-v2.2?
(downloaded 59 times when posting this reply...)

En detail:
I've tried to create a portable appimage of min (browser).
In a temporary working directory i created min-portable subdirectory.
I extracted min-1.21.0-1.x86_64.rpm to /mnt/sda3/temp/min-portable.
I than ran create-portable64, selected /mnt/sda3/temp/min-portable, entered runapp as command.
I created script runapp to launch min with options,
I edited runapp.desktop to match min.desktop.
I tested the AppDir as suggested and all worked as expected.

But creating appimage fails...
I can see a squashfs in /mnt/sda3/temp while it is created (don't recall the exact name), but then it just dissapears.
No errors logged anywhere (logging of X errors enabled)
The only message i can see is in yad dialog*:

quickshot-210830-201819.jpg (53.5 KiB) Viewed 2800 times

*Ist ein Verzeichnis == Is a directory

EDIT:
Seems like i missed the importance of the optional custom name and that there is -portable appended if no custom name is given.
Renamed my AppDir to min and all is well.