Mykyta Holubakha <hiloba...@gmail.com> schrieb am Sa., 6. Okt. 2018 um 13:18 Uhr:
> Signed-off-by: Mykyta Holubakha <hiloba...@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.
