[Interest] Interest Digest, Vol 86, Issue 17

[Roland Hughes]

In the past, when one built a multi-arch Deb it contained everything 
needed to run on both 32-bit and 64-bit platforms. It was its own little 
universe. If you did it correctly, it would also cleanly install via 
alien or other means on RPM based distros. That one file could be walked 
on disk/thumb to any machine because it contained its own little 
universe. A bit of a write up can be found here.

https://medium.com/genymobile/if-appimage-flatpak-and-snap-dont-cut-it-you-can-roll-your-own-6175177d6eef

With all of the other packaging tools, AppImage, snapcraft, flatpak, 
etc. your application is limited to the libraries it provides or can 
find. While you may have something which runs on both 32-bit and 64-bit, 
the one which got installed on the 64-bit tends to not run on the 32-bit 
because it is architecture specific. Can't find the link right now, but 
there was a good write up on the snappy store custom target building I 
read last week.

While the subset of applications this restricted environment can support 
will probably grow some, you can't really be cutting edge. In the case 
of Linuxdeployqt, this means you cannot use a current version of Qt with 
the latest chromium libraries and plug-ins. You have to use the one and 
only version of Qt they support and you need to develop using 14.04. 
Hey, for a text editor or word processor, it is probably enough. Heck, I 
had both of those under DOS with 640K RAM and dual floppies. If you need 
something like Postgresql . . . 
https://github.com/AppImage/AppImageKit/issues/134

These pre-made self-contained little worlds have limits. While one could 
state an AppImage built with linuxdeployqt isn't running in a pre-made 
world like snappy, you will find there are limits to how deep it will 
search for what it bundles into the world it builds for your 
application. If your app needs something the tool won't look for, then 
you will have to do some serious hoop jumping and sledge hammering to 
add things. Assuming they can be added. Postgresql needs an engine 
running on the host.

Building a multi-arch multi-OS-version Debian is tough. I totally 
understand everyone wanting a simple tool for packaging. I've had to 
fight the battle more than I care to admit. It gets even more 
interesting when you encounter the 14.04 64-bit library search path bug. 
If you try to install a 32-bit package on a raw install of 14.04 64-bit 
without internet connection, one which brings all it needs along so it 
can run even though 32-bit arch support hasn't been installed on the OS, 
you find it. Usually with libQt5Core.so  when it finds a matching 
library name in the default search path, despite you having set RPATH 
and PATH, it realizes the library is 64-bit and stops searching the rest 
of the tree. The problem does not exist on 16.04, at least I didn't 
encounter it.

Clear as mud now?

On 11/17/18 5:46 PM, Jean-Michaël Celerier wrote:
> > This may or may not be an issue for you, but, AppImage is something 
> of an inverted philosophy. It's not "one Deb to rule them all" which 
> is how things were done in the past. Each AppImage is built 
> specifically for the target
>
> I don't understand, I'm using AppImage for my software 
> (https://github.com/OSSIA/score/releases) and it works on most linux 
> distros out there (ubuntu, fedora, arch, etc...).
>
> Best,
> Jean-Michaël Celerier
> http://www.jcelerier.name
>
>
-- 
Roland Hughes, President
Logikal Solutions
(630) 205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us