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
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
