AppImage for easy distribution of nightlies and releases
Hello Inkscape developers and maintainers,
today I would like to propose an easy way to run and test Inkscape on various Linux distributions. Inkscape used to provide upstream- packaged Autopackages, but since I could no longer find them, I wonder whether this project might be interested in providing AppImages, which are essentially self-mounting ISOs that contain Inkscape and all dependencies it needs to run that cannot be assumed to be part of the base system (Linux distribution). This means that projects like Inkscape can package once and reach users of most desktop Linux distributions. http://www.appimage.org
Linus Torvalds recently wrote about AppImage: "Sure, it means that the end result is much bigger than a distro-native binary would be, but if you want a way to build applications for your users without limiting them to a particular distribution, or having to build fifteen different images, it really looks like it works very well.=EF=BB=BF" - https://plus.google.com/+LinusTorvalds/posts/WyrATKUnmrS
I prepared an AppImage of the bzr version. You can download it from https://bintray.com/probono/AppImages/Inkscape/_latestVersion#files Simply download, chmod a+x, and run.
The recipe script that generated it is is linked below, in case you want to see how it was done and improve it. Using the recipe, it should also be easy to generate an AppImage for 32-bit systems: https://github.com/probonopd/AppImages/tree/master/recipes/inkscape
I have tested it on a couple of different distributions with success: * CentOS-7-x86_64-LiveGNOME-1511.iso * debian-live-8.0.0-amd64-xfce-desktop+nonfree.iso * elementary_OS_0.3_freya_amd64.iso * Fedora-Live-Workstation-x86_64-23-10.iso * ubuntu-16.04-beta2-desktop-amd64.iso
I had to work around an issue with "undefined symbol: g_type_check_instance_is_fundamentally_a" by bundling glib2, this makes it run also on * antergos-2014.08.07-x86_64.iso * linuxmint-17.3-cinnamon-64bit.iso * ubuntu-14.04.1-desktop-amd64.iso Possibly we can find a cleaner way (e.g., use CentOS 6 as the build host) to make this workaround unneccessary.
Most likely it will run on others, too - and with some fine-tuning of the recipe (i.e., bundling additional dependencies) on even more. Probably the recipe is not perfect yet and might be missing some stuff, but that should be relatively easy to fix.
If there is a continuous build system in place, this could be integrated so that continuous/nightly/weekly images get built. Having such builds should allow more users to run the latest bleeding-edge version, test on multiple systems, and give earlier feedback. Of course the AppImage format could also be used to distribute stable/testing versions to users of most Linux distributions.
I have set up a cloud-based build system where I do the builds on travis-ci using a build system living inside a Docker image generated on Docker Hub. You can see this system in action here: https://github.com/probonopd/AppImages/ Of course this would be even more useful if it was integrated into the official Inkscape build system.
There is also an update mechanism in the works which allows users to download binary deltas between the version they have and the latest version. This works without central servers or repositories, you could run it on your own project infrastructure. Makes updating continuous builds really fast and easy. https://github.com/probonopd/AppImageKit/blob/master/ AppImageUpdate.AppDir/README.md (this is purely optional though).
Is the Inkscape project interested in maintaing an upstream-generated AppImage, as projects like Krita, MuseScore, and Scribus already do? Upstream packaging would have the advantage that users/testers get the software exactly in the way the upstream team intended, with the correct versions of the libraries bundled together with the application. What could be improved?
Regards probono
Wow, I tested the appimage on Ubuntu 15.10 and it just works ... Great achievement!
I guess settings are still saved in conventional paths?
I think AppImages makes a lot of sense for testing out new features / UI changes that are not yet in trunk. Early feedback.
On a side note, I've been working on a Vagrantfile that summons up a VM capable of building Inkscape from source. I wonder how much work it would be to add "appimage"-building capability to that....
https://github.com/objarni/inkup/edit/master/Vagrantfile
Mvh
/Olof ----------------- Är du systemutvecklare? Spana in https://cilamp.se
On 18 April 2016 at 10:18, probono <probono@...3377...> wrote:
Hello Inkscape developers and maintainers,
today I would like to propose an easy way to run and test Inkscape on various Linux distributions. Inkscape used to provide upstream- packaged Autopackages, but since I could no longer find them, I wonder whether this project might be interested in providing AppImages, which are essentially self-mounting ISOs that contain Inkscape and all dependencies it needs to run that cannot be assumed to be part of the base system (Linux distribution). This means that projects like Inkscape can package once and reach users of most desktop Linux distributions. http://www.appimage.org
Linus Torvalds recently wrote about AppImage: "Sure, it means that the end result is much bigger than a distro-native binary would be, but if you want a way to build applications for your users without limiting them to a particular distribution, or having to build fifteen different images, it really looks like it works very well.=EF=BB=BF" - https://plus.google.com/+LinusTorvalds/posts/WyrATKUnmrS
I prepared an AppImage of the bzr version. You can download it from https://bintray.com/probono/AppImages/Inkscape/_latestVersion#files Simply download, chmod a+x, and run.
The recipe script that generated it is is linked below, in case you want to see how it was done and improve it. Using the recipe, it should also be easy to generate an AppImage for 32-bit systems: https://github.com/probonopd/AppImages/tree/master/recipes/inkscape
I have tested it on a couple of different distributions with success:
- CentOS-7-x86_64-LiveGNOME-1511.iso
- debian-live-8.0.0-amd64-xfce-desktop+nonfree.iso
- elementary_OS_0.3_freya_amd64.iso
- Fedora-Live-Workstation-x86_64-23-10.iso
- ubuntu-16.04-beta2-desktop-amd64.iso
I had to work around an issue with "undefined symbol: g_type_check_instance_is_fundamentally_a" by bundling glib2, this makes it run also on
- antergos-2014.08.07-x86_64.iso
- linuxmint-17.3-cinnamon-64bit.iso
- ubuntu-14.04.1-desktop-amd64.iso
Possibly we can find a cleaner way (e.g., use CentOS 6 as the build host) to make this workaround unneccessary.
Most likely it will run on others, too - and with some fine-tuning of the recipe (i.e., bundling additional dependencies) on even more. Probably the recipe is not perfect yet and might be missing some stuff, but that should be relatively easy to fix.
If there is a continuous build system in place, this could be integrated so that continuous/nightly/weekly images get built. Having such builds should allow more users to run the latest bleeding-edge version, test on multiple systems, and give earlier feedback. Of course the AppImage format could also be used to distribute stable/testing versions to users of most Linux distributions.
I have set up a cloud-based build system where I do the builds on travis-ci using a build system living inside a Docker image generated on Docker Hub. You can see this system in action here: https://github.com/probonopd/AppImages/ Of course this would be even more useful if it was integrated into the official Inkscape build system.
There is also an update mechanism in the works which allows users to download binary deltas between the version they have and the latest version. This works without central servers or repositories, you could run it on your own project infrastructure. Makes updating continuous builds really fast and easy. https://github.com/probonopd/AppImageKit/blob/master/ AppImageUpdate.AppDir/README.md (this is purely optional though).
Is the Inkscape project interested in maintaing an upstream-generated AppImage, as projects like Krita, MuseScore, and Scribus already do? Upstream packaging would have the advantage that users/testers get the software exactly in the way the upstream team intended, with the correct versions of the libraries bundled together with the application. What could be improved?
Regards probono
Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2016-04-18 11:52 GMT+02:00 Olof Bjarnason <olof.bjarnason@...400...>:
Wow, I tested the appimage on Ubuntu 15.10 and it just works ... Great achievement!
I guess settings are still saved in conventional paths?
Yes, correct.
I think AppImages makes a lot of sense for testing out new features / UI changes that are not yet in trunk. Early feedback.
On a side note, I've been working on a Vagrantfile that summons up a VM capable of building Inkscape from source. I wonder how much work it would be to add "appimage"-building capability to that....
Cool. In fact I have been doing something very similar but using CentOS 7 and Docker. It would not be that hard to add AppImage generation, see https://github.com/probonopd/AppImages/blob/master/recipes/inkscape/Recipe. However the distribution you are building on should be as old as reasonably possible, because that makes the resulting binaries usable on more systems. I had tried CentOS 6 but then given up because Inkscape seemed to need newer versions of many dependencies (or at least the autotools were thinking so).
cool stuff. It will remove all this dependencies needs. Once several peaple confirmed, we should link directly from our downloadpage
Why should that be compiled using old OS image? I thought using bleeding edge build system you get all the cool features and library improvements only.
Regards, theAdib. --
On Mon, Apr 18, 2016 at 11:24 PM, probono <probono@...3377...> wrote:
2016-04-18 11:52 GMT+02:00 Olof Bjarnason <olof.bjarnason@...400...>:
Wow, I tested the appimage on Ubuntu 15.10 and it just works ... Great achievement!
I guess settings are still saved in conventional paths?
Yes, correct.
I think AppImages makes a lot of sense for testing out new features / UI changes that are not yet in trunk. Early feedback.
On a side note, I've been working on a Vagrantfile that summons up a VM capable of building Inkscape from source. I wonder how much work it
would be
to add "appimage"-building capability to that....
Cool. In fact I have been doing something very similar but using CentOS 7 and Docker. It would not be that hard to add AppImage generation, see https://github.com/probonopd/AppImages/blob/master/recipes/inkscape/Recipe . However the distribution you are building on should be as old as reasonably possible, because that makes the resulting binaries usable on more systems. I had tried CentOS 6 but then given up because Inkscape seemed to need newer versions of many dependencies (or at least the autotools were thinking so).
Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I agree with Adib, with a little more testing it would be great to be able to offer these builds.
probono: if the system building these is multiarch, they'd be able to build for 32bit as well, correct? I have a user who would be willing to test a 32bit build as they're stuck on an ancient release of Ubuntu (a first half of the alphabet release).
Cheers, Josh
On Mon, Apr 18, 2016 at 2:58 PM, the Adib <theadib@...400...> wrote:
cool stuff. It will remove all this dependencies needs. Once several peaple confirmed, we should link directly from our downloadpage
Why should that be compiled using old OS image? I thought using bleeding edge build system you get all the cool features and library improvements only.
Regards, theAdib.
On Mon, Apr 18, 2016 at 11:24 PM, probono <probono@...3377...> wrote:
2016-04-18 11:52 GMT+02:00 Olof Bjarnason <olof.bjarnason@...400...>:
Wow, I tested the appimage on Ubuntu 15.10 and it just works ... Great achievement!
I guess settings are still saved in conventional paths?
Yes, correct.
I think AppImages makes a lot of sense for testing out new features / UI changes that are not yet in trunk. Early feedback.
On a side note, I've been working on a Vagrantfile that summons up a VM capable of building Inkscape from source. I wonder how much work it
would be
to add "appimage"-building capability to that....
Cool. In fact I have been doing something very similar but using CentOS 7 and Docker. It would not be that hard to add AppImage generation, see https://github.com/probonopd/AppImages/blob/master/recipes/inkscape/Recipe . However the distribution you are building on should be as old as reasonably possible, because that makes the resulting binaries usable on more systems. I had tried CentOS 6 but then given up because Inkscape seemed to need newer versions of many dependencies (or at least the autotools were thinking so).
Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2016-04-19 0:27 GMT+02:00 Josh Andler <scislac@...400...>:
I agree with Adib, with a little more testing it would be great to be able to offer these builds.
probono: if the system building these is multiarch, they'd be able to build for 32bit as well, correct?
Yes, it is possible to build AppImages for different architectures. For example, the MuseScore project provides i686 (32-bit), x86_64 (64-bit), and armhf (new 32-bit) https://musescore.org/en/download#AppImage
I have a user who would be willing to test a 32bit build as they're stuck on an ancient release of Ubuntu (a first half of the alphabet release).
The current Inkscape AppImage is built on CentOS 7 which means that it has a dependency on glibc 2.17. So I would expect that you need at least a 2013ish distribution to run the Inkscape AppImage on. A "middle of the alphabet" version of Ubuntu would be Maverick Meerkat alias Ubuntu 10.10, released in 2010. So it will not run there (Ubuntu 13.04 is probably the minimum required for the Inkscape AppImage the way it is currently built; although I didn't test).
This is because in order to save space and redundancy, the AppImage doesn't contain each and every library (starting from glibc itself), but only contains these libraries that cannot reasonably be expected to be part of the base system (which is loosely defined as "not too outdated desktop distributions"). For the dependencies that are not bundled inside the AppImage, the version present at runtime must not be older than the version that was present at compile time (in case of the current Inkscape AppImage, CentOS 7).
If we really want to target systems such as Ubuntu 10.10, there are two options:
1. Get Inkscape to build on a really old system such as Ubuntu 10.10 or older. This way it will not depend on any newer libraries than are in Ubuntu 10.10 (besides the ones we bundle inside the AppImage which are allowed to be newer, als long as they, too, have been compiled on Ubuntu 10.10 or older). This is likely cumbersome, because the current build scripts assume newer versions of many dependencies to be present at build time. As mentioned before, I attempted to build on CentOS 6 (which is from the 2011 era) and didn't succeed (possibly it can be done by an experienced Inkscape developer).
2. Bundle each and every dependency inside the AppImage, including stuff like glibc and GTK.This will make the AppImage significantly larger and its contents more redundant.
So as always, there is a tradeoff. Applications like Firefox or OpenOffice are deliberately built on old systems as to maximize binary compatibility with all but the most recent systems.
More on the background of AppImageKit and its workings on https://github.com/probonopd/AppImageKit/blob/master/README.md
Happy testing!
An appimage would be good for *testing* purposes.
Having it as a general production Inkscape I think is not such a great idea; we already have in place the possibility to build inkscape for a great number of Linux OSes and ending that would not be popular.
Not to mention we'd still need to maintain builds for osx and windows; this would go against the whole cmake work that has been done partially to address that builds system complication. On 19 Apr 2016 08:30, "probono" <probono@...3377...> wrote:
2016-04-19 0:27 GMT+02:00 Josh Andler <scislac@...400...>:
I agree with Adib, with a little more testing it would be great to be
able
to offer these builds.
probono: if the system building these is multiarch, they'd be able to
build
for 32bit as well, correct?
Yes, it is possible to build AppImages for different architectures. For example, the MuseScore project provides i686 (32-bit), x86_64 (64-bit), and armhf (new 32-bit) https://musescore.org/en/download#AppImage
I have a user who would be willing to test a 32bit build as they're stuck on an ancient release of Ubuntu (a first
half
of the alphabet release).
The current Inkscape AppImage is built on CentOS 7 which means that it has a dependency on glibc 2.17. So I would expect that you need at least a 2013ish distribution to run the Inkscape AppImage on. A "middle of the alphabet" version of Ubuntu would be Maverick Meerkat alias Ubuntu 10.10, released in 2010. So it will not run there (Ubuntu 13.04 is probably the minimum required for the Inkscape AppImage the way it is currently built; although I didn't test).
This is because in order to save space and redundancy, the AppImage doesn't contain each and every library (starting from glibc itself), but only contains these libraries that cannot reasonably be expected to be part of the base system (which is loosely defined as "not too outdated desktop distributions"). For the dependencies that are not bundled inside the AppImage, the version present at runtime must not be older than the version that was present at compile time (in case of the current Inkscape AppImage, CentOS 7).
If we really want to target systems such as Ubuntu 10.10, there are two options:
- Get Inkscape to build on a really old system such as Ubuntu 10.10
or older. This way it will not depend on any newer libraries than are in Ubuntu 10.10 (besides the ones we bundle inside the AppImage which are allowed to be newer, als long as they, too, have been compiled on Ubuntu 10.10 or older). This is likely cumbersome, because the current build scripts assume newer versions of many dependencies to be present at build time. As mentioned before, I attempted to build on CentOS 6 (which is from the 2011 era) and didn't succeed (possibly it can be done by an experienced Inkscape developer).
- Bundle each and every dependency inside the AppImage, including
stuff like glibc and GTK.This will make the AppImage significantly larger and its contents more redundant.
So as always, there is a tradeoff. Applications like Firefox or OpenOffice are deliberately built on old systems as to maximize binary compatibility with all but the most recent systems.
More on the background of AppImageKit and its workings on https://github.com/probonopd/AppImageKit/blob/master/README.md
Happy testing!
Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2016-04-19 8:40 GMT+02:00 Olof Bjarnason <olof.bjarnason@...400...>:
An appimage would be good for *testing* purposes.
Agree, ideally we could tie AppImage generation into the existing continuous/nightly build system, if such as thing exists (I could not find recent Linux nightlies in a quick cursory search).
Having it as a general production Inkscape I think is not such a great idea; we already have in place the possibility to build inkscape for a great number of Linux OSes and ending that would not be popular.
Also providing an AppImage would not imply ending anything. it would merely be one additional option for users of less-frequently updated distros to use the latest released Inkscape version on the day when it comes out.
Not to mention we'd still need to maintain builds for osx and windows; this would go against the whole cmake work that has been done partially to address that builds system complication.
Maybe you can clarify; I don't understand how providing AppImages would influence in any way whatever is being discussed on using cmake, OS X or Windows.
On 19 April 2016 at 17:30, probono <probono@...3377...> wrote:
2016-04-19 8:40 GMT+02:00 Olof Bjarnason <olof.bjarnason@...400...>:
An appimage would be good for *testing* purposes.
Agree, ideally we could tie AppImage generation into the existing continuous/nightly build system, if such as thing exists (I could not find recent Linux nightlies in a quick cursory search).
Yes, agree. Having continuous building of AppImages as soon as anyone pushes changes sounds great.
Having it as a general production Inkscape I think is not such a great
idea;
we already have in place the possibility to build inkscape for a great number of Linux OSes and ending that would not be popular.
Also providing an AppImage would not imply ending anything. it would merely be one additional option for users of less-frequently updated distros to use the latest released Inkscape version on the day when it comes out.
Not to mention we'd still need to maintain builds for osx and windows;
this
would go against the whole cmake work that has been done partially to address that builds system complication.
Maybe you can clarify; I don't understand how providing AppImages would influence in any way whatever is being discussed on using cmake, OS X or Windows.
I was reacting to what I perceived as a "let's go with AppImages for everything!" sentiment which I might have misinterpreted in the thread. Sorry.
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?
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.
On 19 April 2016 at 19:10, probono <probono@...3377...> wrote:
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".
How much bigger? 50%? 300%?
The difference between 50 mb and 75 mb is negligable imho.
Especially if that binary-patch-automagic thing you talked about works.
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.
2016-04-19 19:13 GMT+02:00 Olof Bjarnason <olof.bjarnason@...400...>:
How much bigger? 50%? 300%?
That can differ largely depending on the dependency tree of an application. In the case of Inkscape it might indeed be an acceptable overhead. One would have to try. I have never tried to bundle GTK+ myself (and make it relocateable!), but here is someone who has: https://blogs.gnome.org/tvb/2013/12/10/application-bundles-for-glade/
Glade, bundled with a complete GTK+ dependency stack, comes in at 54.1 MB. https://people.gnome.org/~tvb/test-bundles/glade
2016-04-19 23:24 GMT+02:00 probono <probono@...3377...>:
2016-04-19 19:13 GMT+02:00 Olof Bjarnason <olof.bjarnason@...400...>:
How much bigger? 50%? 300%?
An AppImage that contains the full dependency tree would weigh in at around 70-80 MB. However, it seems like I cannot prevent older (bundled) and newer (target system) libraries to become mixed up, resulting in crashes.
After recompiling quite a lot of dependencies, I finally succeeded in compiling the latest Inkscape trunk on CentOS 6. I think that this is the most practicable solution, as it should run on most distributions using glibc 2.14 or newer.
Please test it: https://bintray.com/probono/AppImages/Inkscape/0.91%2Bdevel.r14861.glibc2.14...
Am 19.04.2016 um 17:45 schrieb Olof Bjarnason:
On 19 April 2016 at 17:30, probono <probono@...3377... mailto:probono@...3377...> wrote:
2016-04-19 8:40 GMT+02:00 Olof Bjarnason <olof.bjarnason@...400... <mailto:olof.bjarnason@...400...>>: > An appimage would be good for *testing* purposes. Agree, ideally we could tie AppImage generation into the existing continuous/nightly build system, if such as thing exists (I could not find recent Linux nightlies in a quick cursory search).
There's a trunk ppa for Ubuntu-based distros managed by Alex, which is updated regularly: https://launchpad.net/~inkscape.dev/+archive/ubuntu/trunk
Maren
2016-04-18 23:58 GMT+02:00 the Adib <theadib@...400...>:
cool stuff. It will remove all this dependencies needs. Once several peaple confirmed, we should link directly from our downloadpage
Yes, more testing is required.
Why should that be compiled using old OS image? I thought using bleeding edge build system you get all the cool features and library improvements only.
It's the difference between the (bleeding-edge) app and its immediate depenencies (which indeed you might want to be bleeding-edge; in which case they should be bundled inside the AppImage) vs. the "stable OS" which contains basic platform infrastructure such as glibc, GTK+, etc. These are generally assumed to be part of the OS and should not be bundled with each app.
There might be some special cases in which it can make sense to bundle an entire GTK+ stack inside an AppImage, and it has been done before: https://blogs.gnome.org/tvb/2013/12/10/application-bundles-for-glade/
Hope this clarifies it.
participants (5)
-
Josh Andler -
Maren Hachmann -
Olof Bjarnason -
probono -
the Adib