Offer AppImage, snaps & flatpaks

[rugk]

Offering the new snap & flatpak formats for Linux could allow you. Maybe you can integrate them in your superbuild.

The advantages of snap/flatpak are you only need to support these two distribution types in order to make it available to many distros and they can offer a sandbox for better security.

[dg0yt]

The superbuild solves non-Linux distribution problems by Linux distribution practices (and source packages!). Snap & flatpak are very different from this approach.

Anyway, there is some OBS support for snap:
https://hackweek.suse.com/projects/snap-support-for-obs
https://build.opensuse.org/project/show/home:adrianSuSE:snappy
https://github.com/openSUSE/obs-build/blob/master/build-recipe-snapcraft

and of course
https://snapcraft.io/docs/

[ghost]

It would be much better use AppImage package

• https://github.com/AppImage

Cast @probonopd

[rugk]

Why better, no? AppImage is also a possibility, but it does e.g. have no possibility to sandbox the applications.

[ghost]

AppImageCommunity/pkg2appimage#249

[ghost]

Why better, no?

@rugk, because snap & flatpack are unsecure!

• http://seclists.org/oss-sec/2017/q2/569

but it does e.g. have no possibility to sandbox the applications

What you mean under 'sandbox' for OOMapper?

• https://en.wikipedia.org/wiki/AppImage

[rugk]

First the correct word is "insecure". Secondly the link only talks about flatpaks, not snaps. Thirdly that looks like a vulnerability, which can be fixed which has been fixed as mentioned in the link, you've posted:

Fixed in: 0.8.x >= 0.8.7, all versions >= 0.9.6

But after all, just because there was a vulnerability to escape the sandbox of flatpak/snap, it still means AppImages are way more insecure as they do not have this sandbox at all. So they have full user-rights by default…
So arguing about security does not bring you far, here… 😆

[ghost]

which has been fixed as mentioned in the link, you've posted

It was fixed only few days ago, and nobody know did flatpack not include today.

snap is fully Ubuntu project, that could be dropped in any time (R.I.P. mir... Hello, GNOMEbuntu!)

AppImage already used by Scribus, Krita and many other major open-source projects

• https://github.com/AppImage/AppImageKit/wiki/AppImages

[rugk]

It was fixed only few days ago, and nobody know did flatpack not include today.

This applies to any vulnerability. And in every software vulnerabilities exist. And we don't know the state of AppImage.
As said, security is not a good argument here, so you've switched to different ones.

snap is fully Ubuntu project, that could be dropped in any time

Aha, well…, there is always someone who continues/forks it, but I doubt it will be dropped so fast. ANd if they do, then maybe in favour of flatpaks… 😉 So use them then.

AppImage already used by Scribus, Krita and many other major open-source projects

Sweet, and how does this affect this project?
And here are some flatpaks. Note that in addition to many GNOME applications, Blender, and… uh… Skype and Spotify uses it… http://flatpak.org/apps.html

Searching for snaps I just experienced is horrible as there are all kind of other software with this name… (even some dinosaurs they should really have choosen another name), but here are some images of popular snaps.

In any case we don't need to argue what is better. It likely also won't matter… Of course this can be packaged as appimages and as snaps and as flatpaks. Letting the user to choose what/how to install it, is always good.

[dg0yt]

So much noise, and little of this touching my personal concerns as a user or developer, such as security updates of dependencies, or licensing compliance.

But looks like there is also a link between OBS and AppImage:
https://github.com/AppImage/AppImageKit/wiki/Using-Open-Build-Service
https://build.opensuse.org/package/show/home:probono/QtQuickApp

[dg0yt]

So much noise, and little of this touching my personal concerns as a user or developer, such as security updates of dependencies, or licensing compliance.

And these slides cover it very well:
https://speakerdeck.com/sysrich/opensuse-conference-2017-the-t-rex-was-the-hero-of-jurassic-park#

[probonopd]

#898 builds and uploads an AppImage for each git push. Using OBS would be another option, if you prefer that.

[dg0yt]

For the record, I want to repeat here (from #898) what needs to be known or solved for these kind of packages before we can distribute them:

• The resulting package is large (54 MB now for AppImage at OBS), much more than our other image-style packages. This is due to more numerous and complex dependencies, especially for Qt Assistant/WebKit and for gdal. This can only be reduced if we build the libraries ourselves. Well, we have got the tool (superbuild).
• The licensing of all the bundled libraries needs to be reviewed, and documentation needs to be added to the AppImage as needed. We have got the Infrastructure ("licensing provider" stuff in doc/licensing), but it is a lot of work, given >100 libraries. Again, using our superbuild could help with the effort, by reducing dependencies and using Debian copyright files.
• Where Mapper uses resources which are distributed inside the package, we need to make sure that it really picks up resources from the package. Also resources for Proj.4 and GDAL need to be handled.

[ghost]

The resulting package is large (54 MB now for AppImage at OBS)

Can you give direct link to this AppImage?

[dg0yt]

This AppImage is not published for the reasons given.

[dg0yt]

For the record, this is the list of libs in the 33.2 MB AppImage if NOT deploying Qt Assistant (WebKit). The checked libraries are the ones which are build with superbuild for non-Linux systems. (On the other hand, some libraries seems to be alternative to the ones we use in superbuild, such as libxml2 <-> expat.)

• libavahi-client.so.3
• libavahi-common.so.3
• libbz2.so.1
• libcrypto.so.1.0.0
• libcups.so.2
• libcurl.so.4
• libdbus-1.so.3
• libffi.so.4
• libfreetype.so.6
• libfreexl.so.1
• libgdal.so.1
• libgeos-3.4.2.so
• libgeos_c.so.1
• libgeotiff.so.2
• libgif.so.6
• libglapi.so.0
• libgraphite2.so.3
• libharfbuzz.so.0
• libhdf5_hl.so.10
• libhdf5.so.10
• libhdf.so.4.2.11
• libicudata.so.52.1
• libicui18n.so.52.1
• libicuuc.so.52.1
• libjasper.so.1
• libjbig.so.2
• libjpeg.so.8
• liblber-2.4.so.2
• liblcms2.so.2
• liblcms.so.1
• libldap-2.4.so.2
• libldap_r-2.4.so.2
• libltdl.so.7
• liblzma.so.5
• libmfhdf.so.4.2.11
• libmng.so.1
• libmysqlclient.so.18
• libnetcdf.so.7
• libodbcinst.so.2
• libodbc.so.2
• libopenjp2.so.7
• libpcre16.so.0
• libpcre.so.1
• libpng16.so.16
• libpoppler.so.44
• libpq.so.5
• libproj.so.9
• libQt5Core.so.5
• libQt5DBus.so.5
• libQt5Gui.so.5
• libQt5Network.so.5
• libQt5PrintSupport.so.5
• libQt5Widgets.so.5
• libQt5XcbQpa.so.5
• libsasl2.so.3
• libspatialite.so.7
• libsqlite3.so.0
• libssh2.so.1
• libssl.so.1.0.0
• libtiff.so.5
• libwebp.so.5
• libX11-xcb.so.1
• libXau.so.6
• libxcb-dri2.so.0
• libxcb-dri3.so.0
• libxcb-glx.so.0
• libxcb-icccm.so.4
• libxcb-image.so.0
• libxcb-keysyms.so.1
• libxcb-present.so.0
• libxcb-randr.so.0
• libxcb-render.so.0
• libxcb-render-util.so.0
• libxcb-shape.so.0
• libxcb-shm.so.0
• libxcb-sync.so.1
• libxcb-util.so.1
• libxcb-xfixes.so.0
• libxcb-xkb.so.1
• libXdamage.so.1
• libxerces-c-3.1.so
• libXext.so.6
• libXfixes.so.3
• libXi.so.6
• libxkbcommon.so.0
• libxkbcommon-x11.so.0
• libxml2.so.2
• libxshmfence.so.1
• libXxf86vm.so.1

Looks like there won't be printing without CUPS, which in turn requires OpenSSL or similar... I'm not going to spent more time on this.

[probonopd]

I don't understand what the problem is. What don't you want to spend more time on? Can I help?

[dg0yt]

See what I wrote before:

The licensing of all the bundled libraries needs to be reviewed, and documentation needs to be added to the AppImage as needed. ... it is a lot of work, given >100 libraries.

This is due to the fact that distributing shared object files is subject to common terms such as

• Redistributions in binary form must reproduce the above copyright
  notice, this list of conditions and the following disclaimer in
  the documentation and/or other materials provided with the
  distribution.

And this review has to be repeated for each binary component which is updated. This is different from regular Linux packages, where binary components are distributed independently, packaged with the required documentation.

What would help is if the AppImage tools would not only copy shared objects, but also copyright files. (And that's what we do for our non-Linux packages.)

In addition, since Mapper is GPL V3 licensed and the listed libraries do no longer constitute system libraries when bundled in the AppImage, we we must consider the libraries' source code as being part of the Corresponding Source which must be provided in certain ways (GPL V3 section 6). This will be even more work than adding the documentation!

So I decided to not spent more time on this because it would continuously consume too much of my precious time for the development of the app, while acceptable alternative solutions do exist. (OTOH I didn't close the ticket as wontfix, and the AppImage recipe is available on OBS.)

[probonopd]

I was about to say, OBS can take care for much of this for you... thanks for your detailed explanation.

[ghost]

OBS can take care for much of this for you.

As OBS currently is not automated, lets add AppImage build to superbuild for autobuild each dev pre-release for Linux.

• https://github.com/probonopd/mapper/blob/patch-2/.travis.yml
  • https://github.com/probonopd/mapper/releases/tag/continuous

[dg0yt]

@Symbian9 Probonopd's contribution is tracked in #898. The lack of an AppImage offer from OpenOrienteering is not due to the lack of OBS automation. The biggest piece of work to be done is verifying the legal terms and attributions which needs to be part of this package. It is more than for other platforms (see above).

[probonopd]

The lack of an AppImage offer from OpenOrienteering is not due to the lack of OBS automation.

Hi @dg0yt is OBS a must for an AppImage of OpenOrienteering to be produced? Please comment in my PR which has not been merged for 2 years.

[rugk]

BTW in flatpak you have the concepts of runtimes, which are independently installed "base images" with most common software. As these may include much software, that would likely solve:

• the licenseing problem
• and the "huge size" problem (BTW that is also a little solved by deduplication)

[dg0yt]

@rugk Can you provide links to documentation or examples?

[rugk]

http://docs.flatpak.org/en/latest/dependencies.html?highlight=runtime#runtimes
http://docs.flatpak.org/en/latest/available-runtimes.html