Re: [gentoo-dev] [RFC] [PATCH] appimage.eclass: new eclass

[Bernd Waibel <waebbl@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3213 bytes --]

Mykyta Holubakha <hilobakho@gmail.com> schrieb am Sa., 6. Okt. 2018 um
13:18 Uhr:

> Signed-off-by: Mykyta Holubakha <hilobakho@gmail.com>
>
> I'm proposing to add a new eclass: appimage.eclass, to facilitate
> extraction off AppImage bundles. The rationale is that some upstreams
> have migrated to distributing their proprietary software exclusively as
> AppImage bundles. (for instance dev-util/staruml-bin).
>
> An example ebuild can be seen at https://git.io/fx3Mg
>
>
I was also thinking of something, too. This direction of development
happens for a couple of years already, with more and more vendors /
upstream jumping on it. It was also highly recommended by Linus Torvalds as
a way of distributing packages easily along different linux flavors. I
don't think we should easily deny the direction where this is going.

Most appimages are distributed through central well-known servers. The
files have a sha1 BuildID attached to them (can be seen via file command),
which can possibly be used to verify them, so decreasing the possible
vulnerability to such packages somewhat. There might also be additional
ways to verify the integrity of them through the appimage API. They are
statically linked packages with no external dependencies, and contain a
squashfs filesystem in it.

From a users point of view, I think it'd be a good idea, to give users the
possibility of installing appimages with the package manager, so they can
be handled accordingly, instead of just let them download the files and
move them into a separate folder in ${HOME} for execution. This would be
especially useful for propietary bin-packages, as well as for some big
packages, which are actually hard to maintain for proxy-maintainers, and
therefore get removed from the tree (freecad comes to my mind as an
example).

2. Are we OK with executing AppImage bundles downloaded from the
> Internet (an alternative would be to implement a proper extractor
> program, which would unpack the images without executing them, and add
> it to DEPENDs).
>

It think, this has mostly the same attack vectors which apply for
bin-packages. So there's not much new from my point of view.


> +# @FUNCTION: appimage_src_unpack
> +# @DESCRIPTION:
> +# Unpack all the AppImage bundles from ${A} (with .appimage extension).
> +# Other files are passed to regular unpack.
>

I'm not sure, if it makes sense to unpack them. Most of them are not built
on gentoo systems, so the extracted binaries and libraries might not easily
run without having the ebuild maintainer check every single one of them for
run-time dependencies.

For example, the freecad appimage contains a bin/mkdir program linked
against libselinux.so.1 which is not available on non-selinux profiles by
default, or its usr/lib/freecad/lib/DraftUtils.so, a freecad internal
library, links against libboost_system.so.1.55.0 while we have
libboost_system.so.1.65.0.

I would propose to keep them packed and install them in /opt/AppImages or
something like that, thus providing only a src_install function with the
eclass. Ebuild maintainers could then just add a .desktop file or extract
one from the image if it's present and add it to the files/ directory for
desktop integration.

[-- Attachment #2: Type: text/html, Size: 4095 bytes --]