2016-04-19 17:45 GMT+02:00 Olof Bjarnason <olof.bjarnason@...400...>:
> But now that you forced me to re-read the thread, I am also curious to why
> it's not
> possible to build&package on newer distributions, and be able to run on
> older...?
> As the dependencies are bundled into the ISO this should be possible?

Basically we have choice between two options:

Option 1: Include _all_ dependencies (besides the kernel) inside the
AppImage. Advantage: Will run on target systems older than the build
system. Disadvantage: AppImage will be rather large and contain many
redundant libraries, doesn't feel "clean".

Option 2: Include only those dependencies in the AppImage that cannot
be assumed to be part of all distros we are targeting. Advantage: The
AppImage will be reasonably sized (roughly in line or even below the
dmg for OS X and Windows msi). Disadvantage: the AppImage will usually
NOT run on target systems older than the build system. Attempting to
run the AppImage on older target systems will result in unresolved
symbols (becuase the application and/or libraries inside the AppImage
will try to access symbols on target system libraries which won't
exist there if the target systems is older than the build system).
Example: We decide not to include glibc in the AppImage because we
assume glibc to be present on each target system. This means that the
application and libraries which are contained inside the AppImage will
try to resolve symbols using the target system glibc at runtime. If
the target system glibc does not contain symbols that were present in
glibc during build time, then the result will be "unresolved symbols",
and the application will not run. This holds true for other libraries
as well.

Note that this is not an either/or thing. We can decide for each
library whether we want to bundle it inside the AppImage or rely on
the library being part of the target system. However, libraries
themselves have dependencies on other libraries, and this whole
dependency tree needs to be taken into consideration.
For most scenarios, a reasonable balance between AppImage size and
compatibility can be achieved by compiling on old build systems,
because then we can assume that the libaries on the target system will
be "recent enough" (relative to the AppImage) and contain (at least)
all the symbols that were there during build time.

In practice, the AppImage builds produced on CentOS 6 by Scribus,
Subsurface, and MuseScore have been working for most real-life users.
So far I did not get Inkscape bzr to build on CentOS 6 but possibly
someone with more experience could get it to build there or on a
similarly "mature" build system. In the meantime, I have used CentOS
7.