[aur-general] PKGBUILD for an .AppImage
I searched through the forums and can't find anything on packaging an AppImage. The only app referenced (upwork-appimage) is no longer available. The particular AppImage in question is: https://github.com/robert7/nixnote2/releases How do I search this mailing list online? What advice would you give with .AppImages? I *could* rip it open, but the only snag I hit was the binary is linked to `libhunspell-1.3.so.0` whereas Arch has `/usr/lib/libhunspell-1.6.so.0`. Would it be a no-no to install this previous libhunspell version in /usr/lib? If using an unextacted AppImage, where should I install the .AppImage itself? /usr/bin/$pkgname.AppImage with a simlink from /usr/bin/$pkgname? Cheers, -- Tom Hale
On 10/11/18 8:12 AM, Tom Hale wrote:
I searched through the forums and can't find anything on packaging an AppImage.
The only app referenced (upwork-appimage) is no longer available.
The particular AppImage in question is: https://github.com/robert7/nixnote2/releases
How do I search this mailing list online?
What advice would you give with .AppImages?
I *could* rip it open, but the only snag I hit was the binary is linked to `libhunspell-1.3.so.0` whereas Arch has `/usr/lib/libhunspell-1.6.so.0`.
Would it be a no-no to install this previous libhunspell version in /usr/lib?
If using an unextacted AppImage, where should I install the .AppImage itself?
/usr/bin/$pkgname.AppImage with a simlink from /usr/bin/$pkgname?
Cheers,
Looks like nixnote2 is already on the AUR and properly built from source, both stable and -git. A binary package ripped from an AppImage is probably the last thing you should be proposing... -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On 11 October 2018 13:27:40 Robin Broda via aur-general <aur-general@archlinux.org> wrote:
On 10/11/18 8:12 AM, Tom Hale wrote:
I searched through the forums and can't find anything on packaging an AppImage.
The only app referenced (upwork-appimage) is no longer available.
The particular AppImage in question is: https://github.com/robert7/nixnote2/releases
How do I search this mailing list online?
What advice would you give with .AppImages?
I *could* rip it open, but the only snag I hit was the binary is linked to `libhunspell-1.3.so.0` whereas Arch has `/usr/lib/libhunspell-1.6.so.0`.
Would it be a no-no to install this previous libhunspell version in /usr/lib?
If using an unextacted AppImage, where should I install the .AppImage itself?
/usr/bin/$pkgname.AppImage with a simlink from /usr/bin/$pkgname?
Cheers,
Looks like nixnote2 is already on the AUR and properly built from source, both stable and -git. A binary package ripped from an AppImage is probably the last thing you should be proposing...
I am the packager of the -git package and will likely disown the pinned package. Could you justify your assertion? It seems I will need to go with the whole appimage... Upstream won't change the linkage to a versioned library filename. -- Tom Hale
On 10/11/18 12:53 PM, tom@hale.ee wrote:
Looks like nixnote2 is already on the AUR and properly built from source, both stable and -git. A binary package ripped from an AppImage is probably the last thing you should be proposing...
I am the packager of the -git package and will likely disown the pinned package.
Could you justify your assertion?
It seems I will need to go with the whole appimage... Upstream won't change the linkage to a versioned library filename.
The fundamental purpose of AppImage is to offer standalone software that does not integrate with the package manager, in return for not depending on the package manager. What is the point of packaging one into a pacman package? If people wanted appimages they would download them and run them as intended... not by extracting the contents and incompletely copying them to /usr Programs which build using private libraries belong in /opt either way, definitively not in /usr/lib. -- Eli Schwartz Bug Wrangler and Trusted User
On 12/10/18 12:06 am, Eli Schwartz via aur-general wrote:
The fundamental purpose of AppImage is to offer standalone software that does not integrate with the package manager, in return for not depending on the package manager.
What is the point of packaging one into a pacman package? If people wanted appimages they would download them and run them as intended... not by extracting the contents and incompletely copying them to /usr
The advantages I see of packaging an AppImage are: * Automatic updates * GUI integration (eg appname.desktop file and icon) * Easy access to man pages, help docs and changelog * Easy access to files (eg skeleton config files) specified in the help docs
Programs which build using private libraries belong in /opt either way, definitively not in /usr/lib.
Cheers, I'll symlink to there. -- Tom Hale
On 10/13/18 2:06 PM, Tom Hale wrote:
The advantages I see of packaging an AppImage are:
* Automatic updates
Automatic in what sense
* GUI integration (eg appname.desktop file and icon) * Easy access to man pages, help docs and changelog * Easy access to files (eg skeleton config files) specified in the help docs
Why would that require AppImage in the loop? Literally none of your points have anything to do with AppImages. -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On 13/10/2018 14:34, Robin Broda via aur-general wrote:
On 10/13/18 2:06 PM, Tom Hale wrote:
The advantages I see of packaging an AppImage are:
* Automatic updates
Automatic in what sense
* GUI integration (eg appname.desktop file and icon) * Easy access to man pages, help docs and changelog * Easy access to files (eg skeleton config files) specified in the help docs
Why would that require AppImage in the loop?
Literally none of your points have anything to do with AppImages.
I believe Tom is pointing to the advantages of deploying an AppImage via a PKGBUILD, rather than of the AppImage format itself. Essentially, using an AppImage as a package `source` like an RPM/deb or other non-native packaging archive. I've seen some projects [citation needed] provide only an AppImage and building from source is non-trivial, so being able to "package" the AppImage could make it easier to use within Arch.
On 10/13/18 4:36 PM, Jonathon Fernyhough wrote:
I believe Tom is pointing to the advantages of deploying an AppImage via a PKGBUILD, rather than of the AppImage format itself. Essentially, using an AppImage as a package `source` like an RPM/deb or other non-native packaging archive.
Then what he's referring to aren't the 'advantages of packaging an AppImage', but rather the advantages of packages as a whole - and even then it's not really accurate. I don't think going off on a tangent about the benefits of system packages is relevant to the topic, anyways.
I've seen some projects [citation needed] provide only an AppImage and building from source is non-trivial, so being able to "package" the AppImage could make it easier to use within Arch.
That's not the case here though, as we have source builds for the program in question. If there are upcoming issues with the source build, those should be patched upstream or in the PKGBUILD instead of abandoning it in favor of a -bin package. -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On 10/13/18 8:06 AM, Tom Hale wrote:
The advantages I see of packaging an AppImage are:
* Automatic updates
Not only is this not automatic when using pacman or even when using an AUR helper, the AppImage format has the ability to self-update via a UI exposed within the application itself (see libappimageupdate) using a manifest embedded within the AppImage. It also supports binary deltas. Updates can be automatically run in the background or triggered by a popup.
* GUI integration (eg appname.desktop file and icon)
appimaged will monitor your system for AppImages, and integrate them via desktop files and icons.
* Easy access to man pages, help docs and changelog
I have rarely ever seen a pacman package that makes use of changelogs, and the ones I do see, are invariably changelogs for the PKGBUILD itself, not for the program. Please do explain how AppImages as sources, over any other type of source, are *more* likely to have any of the three. I wasn't aware it was customary to provide those in AppImages. Probably due to the format being all about isolation vs. natively integrating with the system.
* Easy access to files (eg skeleton config files) specified in the help docs
What applications actually provide skeleton config files? The defaults will be buried in program logic and written out by functions that interpret the format in the first place -- skeleton configs would be rather bloated and pointless according to that logic, and if you just want documentation on the default values, then most programs either document that, come with options to reset to defaults, or in the worst-case scenario, allow you to blow away your settings. There's an incredible degree of inconsistency within the general application ecosystem, between programs which have no default config files and only write out the settings which are non-default, programs which have an embedded scripting language in which all configuration must be *programmed*, programs which store their configurations as some weird binary format (I'm looking at you, gtk/gnome), or simply programs where the defaults are obtained by blowing away your configuration, then starting the program. Occasionally, a program even comes with skeleton config files. o_O Although one of those programs, GnuPG, actually stopped on the grounds that they get stale and since they're nothing but documentation, they should simply ship as documentation, not skel files which contain copies of the documentation. This is a healthy attitude. -- Eli Schwartz Bug Wrangler and Trusted User
participants (5)
-
Eli Schwartz
-
Jonathon Fernyhough
-
Robin Broda
-
Tom Hale
-
tom＠hale.ee