TheAssassin

In either case, you'd need to touch the build system. But then again, there is no reason not to keep those stable.

> But the bare minimum needed, I think, is that changes in type2-runtime need to trigger a build of appimagetool. So that any potential issues are seen by developers immediately....

> As evidenced today. By accident or so. Not by intention. It's been fixed.

> When either happens, an older appimagetool will no longer work. > This just seems way too fragile for me. Just make releases and reference a _specific_ release from appimagetool....

> Someone would need to take time to make releases (you know that I don't like this burden) We've agreed to do those more than once because they make sense...

> Can happen anytime again. In fact, will happen again - only a matter of time. You can say that about _any_ bug. See, today you introduced a few quick...

"Autodetection" has proven to be problematic in the past in appimagetool and that is the main reason I dislike it. For instance, a variety of AppImages I use are built...

It sounds really, really useful considering application security. I can imagine scenarios where a malicious application tries to call system binaries (e.g. accidentally with a `setuid` bit set) that could...

He asks if it's worth porting this to AppImageKit, too.

What do you mean, how? Just do it the way KDE do it: I guess you just have to preload the same libraries.