<div dir="ltr"><div>Hi,<br></div><div><br></div><div>Also to read in this thread :</div><div><br></div><div><a href="https://discourse.appimage.org/t/will-a-new-appimage-run-on-older-distributions/84">https://discourse.appimage.org/t/will-a-new-appimage-run-on-older-distributions/84</a></div><div><br></div><div>"Probono" is the AppImage toolkit author, and he explains well the problematic of binary compatibility issue with older systems.</div><div><br></div><div>I would also add a comment here:</div><div><br></div><div>I have spent my main free time since a few years ago to maintain all the bundles (AppImage, Windows, and MacOS). This job is time consuming, it's very important to promote the project on the main platform.</div><div><br></div><div>Even if the application is packaged on Linux, it's not up-to-date quickly. This is the goal of AppImage, to provide all days a runnable version to test the last change very quickly. It's not perfect, even if i improve all day by day as i fixed a huge problem to support internationalization in the search tool of digiKam 7.6.0 (typically using non latin1 characters do not work on AppImage < 7.6.0 in search text string everywhere in digiKam).</div><div><br></div><div>MacOS and Windows also need to be packaged by the team, we have no other choice.</div><div><br></div><div>And remember that in the future, I'm sure that Windows and MacOS will require signed installers for security reasons, which require to pay at least 100euros to Apple and M$, which is unacceptable for open source projects (this is my viewpoint of course).</div><div><br></div><div>To resume about AppImage : I think it's the best and quick solution to use a prepackaged Linux version, fine tuned by the team. It is just a simple file to execute, nothing to install, nothing is installed. It's simple, but not perfect of course with compatibility. There are also Flatpak and Snap packages which run in a sandbox for security reasons. Sure it's more safe, but it's the hell to use and configure. I don't like these packaging systems. <br></div><div><br></div><div>Best</div><div><br></div><div>Gilles Caulier<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 30 janv. 2022 à 10:17, Remco Viëtor <<a href="mailto:remco.vietor@wanadoo.fr">remco.vietor@wanadoo.fr</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On dimanche 30 janvier 2022 09:58:16 CET Chris Green wrote:<br>
> Andrew Goodbody <<a href="mailto:ajg02@elfringham.co.uk" target="_blank">ajg02@elfringham.co.uk</a>> wrote:<br>
> > The internet suggests that Linux Mint 19 has glibc version 2.27. That<br>
> > message suggests that the appimage was built using glibc version 2.29.<br>
> > This will prevent the appimage from running on Linux Mint 19.<br>
> <br>
> That does rather make an appimage pointless doesn't it?  I thought the<br>
> whole idea was that an appimage brought all its libaries with it.<br>
As far as possible, yes. See Gilles Caulier's message earlier in the thread <br>
why glibc isn't included, and why the minimum version was updated. <br>
Also, keep in mind that Mint 19 is about 4 years old now.<br>
<br>
<br>
<br>
</blockquote></div>