Hi @adrianS and welcome to AppImage. Great to have you here.
I think OBS and AppImage are made for each other. What users like about application bundles like AppImage is that they can get an application directly from an original author’s download page, and run it without having to deal with repositories, without needing root rights, and without changing any of the system-provided libraries. AppImage gives upstream application authors the ability to reach end users directly, without going through the normal distribution process. But as always, with great power comes great responsibility: With application bundles like AppImage, the person who puts together the AppImage needs to take care that all the ingredients (e.g., executables, but also shared libraries) are updated. This can be tedious to do by hand, but luckily proven distribution mechanisms exist for doing exaxtly this, and OBS can make these very mechanisms accessible for building AppImages.
So, I think your contribution is very valuable.
Converting .AppImage files out of rpms during build of rpm.
This means that for all the applications already being built on OBS today, there is an easy way to additionally provide AppImages, which is great.
a Recipe file is optional for AppImage specific things
This should be documented a bit, using examples. I tried to get away from telling people to “just write a bash script” to using more formalized yml files, and a generic “meta” recipe that uses the variables defined in the yml file to do the actual conversion. It would be cool if the same yml file format could be used for both ppa/deb-to-AppImage and for (new) obs-repo/rpm-to-AppImage conversions.
Signing of AppImage files
Does this work automagically because OBS already has a GPG key for each user?
Publishing of AppImage files
Update zsync stuff is WIP
Excellent. I think this is actually a very important, yet often-overlooked piece to the application bundle story. Having binary delta (zsync based) updates that are super easy for both the person creating the AppImage as well as for users is key. Heck, one could even imagine that once a security update for
libfoo comes out, OBS automagically rebuilds all the AppImages that use it (that’s what I mean when I say “OBS can bring the power of existing distribution tools to application bundles”).
Now, what could I imagine to make this even more useful?
Make the oldest still-supported LTS the default for building the ingredients that go into an AppImage. The reason is that not all dependencies should go into an AppImage, only those that cannot reasonably be expected to be part of the target system(s) in a recent enough version. Technically, the person who makes the AppImage can decide which “target systems” to consider. For all practical reasons, I recommend to target the oldest still-supported LTS distributions. The resulting AppImages will run on distributions no older than the build system used for compiling the ingredients. CentOS 6 could be a suitable choice, because it is a very mature system (read: old glibc and friends) but recent compilers are still available for it through Software Collections. I don’t know what the SUSE/openSUSE equivalent for this is, but something like it (or debian oldstable?) would definitely be good candidates.
Remove the requirement to (also) build rpm/deb packages (which can be more tedious at times than necessary for “just” generating an AppImage).
Automatically feed the metadata about the generated AppImages into AppStream feeds, so that sites like http://linux-appimages.org/ could pick it up easily in an automated way.