#Obs qt platform update
#Obs qt platform software
#Obs qt platform code
#Obs qt platform Offline
#Obs qt platform download

AppStream AppImage has no *.desktop file and hence does not launch.

I’d love to see something like SLES_11 as the default rather than openSUSE_Leap_42.1 ( reason).

The first AppImage I (randomly) picked, basket5-2.50+git20160311.9c363a1_3.4.glibc2.2.5-x86_64.AppImage, runs well for me on KDE neon useredition.

The server should be configured to send headers that make the browser save AppImages as files, rather than trying to display their contents in the browser.

There are already many example AppImages at.

Automatically feed the metadata about the generated AppImages into AppStream feeds, so that sites like could pick it up easily in an automated way.

Remove the requirement to (also) build rpm/deb packages (which can be more tedious at times than necessary for “just” generating an AppImage).

I don’t know what the SUSE/openSUSE equivalent for this is, but something like it (or debian oldstable?) would definitely be good candidates.

#Obs qt platform software

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. The resulting AppImages will run on distributions no older than the build system used for compiling the ingredients. For all practical reasons, I recommend to target the oldest still-supported LTS distributions. Technically, the person who makes the AppImage can decide which “target systems” to consider. 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. Make the oldest still-supported LTS the default for building the ingredients that go into an AppImage.Now, what could I imagine to make this even more useful?

#Obs qt platform update

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”). Having binary delta (zsync based) updates that are super easy for both the person creating the AppImage as well as for users is key. I think this is actually a very important, yet often-overlooked piece to the application bundle story. 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.ĭoes this work automagically because OBS already has a GPG key for each user?Įxcellent. 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. This should be documented a bit, using examples. 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.Ī Recipe file is optional for AppImage specific things AppImage files out of rpms during build of rpm. So, I think your contribution is very valuable.Ĭonverting. 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.

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. AppImage gives upstream application authors the ability to reach end users directly, without going through the normal distribution process.

#Obs qt platform download

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. I think OBS and AppImage are made for each other.

I have some kind of support added to OBS ( ) for building AppImage files.

#Obs qt platform Offline

Hopefully we can find a way for a more generic approach for offline builds.

#Obs qt platform code

Both depends also on some cleanup/refactoring work to make our code more generic.

useful when just new maintenance/security updates of used libraries shall get repackaged.

yml files for converting packages without the need of compiling them.

A base project just providing the basic packages exists here ( ).

Publishing of AppImage files (Example: ).

spec file is needed, a Recipe file is optional for AppImage specific things. JFYI and because probono asked for a discussion here.