AppImages with "everything" from up-to-date systems (using makeaoi)?

[Dirk Hohndel]

> On Jul 9, 2017, at 4:09 PM, Lutz Vieweg <lvml at 5t9.de> wrote:
> 
> On 07/02/2017 12:30 AM, Dirk Hohndel wrote:
>> - I haven't figured out how to build an AppImage with Qt 5.9.1
> 
> Is that issue still open?

Yes. My todo list has grown past 100 items...

> I am asking, because I recently published a tool "makeaoi" -
> https://github.com/lvml/makeaoi
> - that implements kind of the "opposite" approach than usual
> to create application images:
> 
> Instead of compiling the application on some "old" operating system
> specifically in preparation to make it "run on almost any system",
> the approach with "makeaoi" is to create an application image on
> whatever (even very new) system the application is already running
> on, without re-compiling it, by having all its (library and data file)
> dependencies traced and conveniently packed into an overlay file system
> that, on the target system, is mounted via unionfs-fuse "on top of /"
> (without root privileges).
> 
> I used it successfully to package some new application versions
> (such as RawTherapee 5.1) to run them on older CentOS systems, and
> making such images from pre-existing binaries is really only a matter
> of minutes.

That sounds fascinating. Tell us more.

>> - none of the distros for which we build distro specific binaries is even
>>   on 5.9, let alone 5.9.1
> 
> Arch Linux does ship Qt 5.9.1 currently.

Yes, but we (i.e., I) don't build binaries for Arch. One of our developers
does this (and right now I'm spacing on who it is - how embarrassing).

> I created an AppImage via makeaoi from the Arch-supplied subsurface-4.6.4,
> and it works well (at least on my CentOS laptop), which one notable exception:
> 
> Accessing device files is (due to FUSE restrictions) limited to a
> "faked via regular files" mode I patched into unionfs-fuse, and while
> that works very well for the usual /dev/urandom, /dev/zero etc. accesses,
> it does not yet support ioctl() stuff like subsurface needs to do
> on device files connecting to dive computer hardware.

Ah, that's a bummer.

> Now I wonder whether it would be worth putting further efforts into
> such a "userspace device file"-emulation.
> Personally, I do not need an AppImage of subsurface, and other software
> that I package this way does not usually need to access devices directly.
> 
> That's why I'm asking here if people are interested in pursuing the
> "make AppImages from existing binaries on up-to-date systems" path, at all?

I certainly think this sounds extremely interesting. But I worry about things
like BT, BLE, device access.

> BTW: The subsurface-x86_64.AppImage I created on Arch has a size of
> 150 MB - so even with all the stuff from glibc to zoneinfo files in it,
> that's still a tolerable size, IMHO.
> (For reference, find the "packlist.txt" file listing the files and
> directories that I packed into this image attached.)

Yikes. That is big.

> BTW2: When run in a user namespace, subsurface aborts with:
>>      > unshare -r /usr/bin/subsurface
>>      You are running Subsurface as root. This is not recommended.
>>      If you insist to do so, run with option --allow_run_as_root.
> Thus I needed to add --allow_run_as_root to my "AppRun" manually.
> (The "unshare -r" is required to allow unprivileged users to "chroot"
> into the user mounted union filesystem on the target system.)

Obviously one could build a version with that flag disabled. I assume
the app drops privileges, correct?

/D