[aur-general] PKGBUILD for an .AppImage

[Tom Hale]

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,

[Robin Broda via aur-general]

I searched through the forums and can't find anything on packaging an AppImage.
The only app referenced (upwork-appimage) is no longer available.
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...

[t***@hale.ee]

On 11 October 2018 13:27:40 Robin Broda via aur-general

Post by Robin Broda via aur-general

I searched through the forums and can't find anything on packaging an AppImage.
The only app referenced (upwork-appimage) is no longer available.
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

[Eli Schwartz via aur-general]

Post by t***@hale.ee

Post by Robin Broda via aur-general
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.

[Tom Hale]

Post by Eli Schwartz via aur-general
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

Post by Eli Schwartz via aur-general
Programs which build using private libraries belong in /opt either way,
definitively not in /usr/lib.

Cheers, I'll symlink to there.

[Robin Broda via aur-general]

Post by Tom Hale
* Automatic updates

Automatic in what sense

Post by Tom Hale
* 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.

[Jonathon Fernyhough]

Post by Robin Broda via aur-general

Post by Tom Hale
* Automatic updates

Automatic in what sense

Post by Tom Hale
* 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.

[Robin Broda via aur-general]

Post by Jonathon Fernyhough
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.

Post by Jonathon Fernyhough
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.

[Eli Schwartz via aur-general]

Post by Tom Hale
* 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.

Post by Tom Hale
* GUI integration (eg appname.desktop file and icon)

appimaged will monitor your system for AppImages, and integrate them via
desktop files and icons.

Post by Tom Hale
* 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.

Post by Tom Hale
* 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.