Dependencies on AppImages

thomasqueirozb · 2020-03-23 00:57:56

each AppImage has no dependencies

I packaged the Session Messenger AppImage on the AUR, but I'm not sure about any of the dependencies, I just copied them from the original non-AppImage package. I'm not sure if packages such as libnotify and xdg-utils (and others) are necessary to be dependencies on the AppImage or I can safely remove them all.

I'm really lost on this dependency stuff because if I run the file command on the AppImage I get the following output:

session-messenger-desktop-linux-x86_64-1.0.5.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, stripped

And if I try to check what it is linked to with ldd (since file says it is dynamically linked) I get this:

	not a dynamic executable

eschwartz · 2020-03-23 01:30:27

That package is a duplicate of "the original non-AppImage package" -- why do you think this is needed?

Last edited by eschwartz (2020-03-23 02:20:46)

thomasqueirozb · 2020-03-23 03:34:03

It isn't a duplicate. My package is the AppImage and the other one is the deb package. The deb package includes many things like icons, locales (.pak) and other resources. Running ldd on the deb package binary gives me a 96 line long output.

eschwartz · 2020-03-23 03:38:10

thomasqueirozb wrote:

It isn't a duplicate. My package is the AppImage and the other one is the deb package.

They both provide the same software in prebuilt binary form, one packed in an appimage, the other packed in a .deb.

Why do you feel the appimage is *distinct* enough to qualify as its own unique package? What benefits does it bring over the .deb version, and if such benefits exist, shouldn't the -bin package be updated to use the appimage file?

thomasqueirozb wrote:

The deb package includes many things like icons, locales (.pak) and other resources.

So the deb is more useful?

thomasqueirozb wrote:

Running ldd on the deb package binary gives me a 96 line long output.

So is this a good thing or a bad thing? Why does it even matter as a thing? What does it mean?

Last edited by eschwartz (2020-03-23 03:39:50)

thomasqueirozb · 2020-03-23 12:04:52

Yes you are correct. Both packages do provide a binary of the same software. The thing is, the AppImage depends on no external libraries (as shown by the output of the ldd command) and the .deb depends on 96 external libraries. If the Debian/Ubuntu repos do not update one of those (96) libraries as fast as Arch does, it won't run anymore. That is the benefit of using an AppImage. If you grab this binary 10 years from now and run it, there probably will be no problems.

The downside of the AppImage is that it is significantly larger than the .deb. The .deb is about 20mb smaller, but doesn't provide the same stability. This is why I created a new package and didn't suggest the owner of the -bin to change to the AppImage. These are 2 distinct ways of distributing binaries and this is why I thought it was worth its own package.

eschwartz · 2020-03-23 12:33:48

Do you understand what an appimage is?

Trilby · 2020-03-23 12:35:31

thomasqueirozb wrote:

the AppImage depends on no external libraries...

FALSE. If you had even tried to run your own package, you would see that. I tried running it, it errored out saying it required a fuse library which I found to be provided by fuse2. I installed fuse2 and tried again, then it errored out saying it required a library that I found to be provided by gtk3. I stopped there as I'm not about to installed gtk3.

As far as the "one file" versus "many files" point, that's complete nonsense. The appimage is just a compressed filesystem including lots of files. Meanwhile a .deb is an archive of many files bundled into one file: one .deb!

Last edited by Trilby (2020-03-23 12:38:08)

eschwartz · 2020-03-23 12:38:44

Well, gosh, if the ldd command showed that it has no dependencies, how dare you suggest otherwise, Trilby.

(But this leads into my question of: "what is a appimage, actually"? The answer is alarming, and ties into the reason why I consider installing an appimage to /usr/bin to be a completely unacceptable way to write a PKGBUILD.)

Trilby · 2020-03-23 12:58:48

I'm glad you're hear to hold back much of the foolishness. Your title should be changed from "Trusted User" to "Guardian of Sanity".

Arch Linux

#1 2020-03-23 00:57:56

Dependencies on AppImages

#2 2020-03-23 01:30:27

Re: Dependencies on AppImages

#3 2020-03-23 03:34:03

Re: Dependencies on AppImages

#4 2020-03-23 03:38:10

Re: Dependencies on AppImages

#5 2020-03-23 12:04:52

Re: Dependencies on AppImages

#6 2020-03-23 12:33:48

Re: Dependencies on AppImages

#7 2020-03-23 12:35:31

Re: Dependencies on AppImages

#8 2020-03-23 12:38:44

Re: Dependencies on AppImages

#9 2020-03-23 12:58:48

Re: Dependencies on AppImages

Board footer