Ship both libappimage and libappimageupdate in PPAs

[TheAssassin]

Pre-submit checks

• [X] I checked for similar issues beforehand, but could not find any. I could not add my proposal to any existing issue.
• [X] I am going to take the time to to fill in all the required details. I know that the bug report will be dismissed otherwise.

Feature description

Currently, the binaries built in the PPAs use some very outdated libappimage, and do not support AppImageUpdate at all.

Proposed solution

We should provide our own libappimage and libappimageupdate packages in the PPA. They should likely be proprietary (e.g., reside in /usr/lib/<triplet>/appimagelauncher and the packages should be called, e.g., libappimage-appimagelauncher, appimagelauncher-updater).

Alternative solutions you considered

Shipping both libraries as part of the main packages most likely breaks our ability to just pull the code from GitHub. Both dependencies are managed as submodules, which means that we'd have to pull in the code somehow before the build. It should be easier to manage those two dependencies separately (as well as their own dependencies). We can recycle some packaging from Debian.

Additional context

No response

[TheAssassin]

CC @RogueScholar @shoogle.

[shoogle]

@TheAssassin, it's a while since I looked at this. Is the problem that Launchpad doesn't pull in the code for the submodules, so it relies on an ancient version of libappimage provided by the distribution? If so, I can think of 2 ways to solve it.

Method 1: Separate PPA builds

This is what you suggested above: create separate PPA builds for libappimage and libappimageupdate and install them to a versioned folder on the user's machine to avoid conflicts with distro packages (I think the convention is to use /opt for versioned packages, here's an example with Qt). If you forgot how to set this up from scratch, I wrote a guide for the author of Touchegg. You only need from Step 3 onwards because you'll be building in the same PPA as AppImageLauncher itself to allow for dependencies to be resolved properly.

The advantage of this method is that you will have created some Debian packaging that a maintainer could use to get libappimageupdate in Debian. The disadvantage is that you have to create that packaging 😉 and remember to click those buttons on on the Launchpad recipe dashboard to get it building for each new Ubuntu release, like you already do for AppImageLauncher.

Method 2: Modified recipe

Another way to solve the issue is to modify the AppImageLauncher build recipe:

# git-build-recipe format 0.4 deb-version {time}-stable-{git-commit}
lp:appimagelauncher stable
merge packaging lp:~appimagelauncher-team/appimagelauncher/+git/packaging launchpad
nest libappimage lp:libappimage lib/libappimage 36691c47fc
nest libappimage lp:~appimagelauncher-team/appimagelauncher/+git/AppImageUpdate lib/AppImageUpdate b6cfe00a13

Lines 4 and 5 (i.e. the bottom two lines) are new. This page describes what the nest keyword does:

The nest keyword puts the contents of one branch into a specific location in another branch

In other words, lines 4 and 5 pull code in from Git repositories on Launchpad that mirror libappimage and AppImageUpdate respectively. The libappimage mirror already exists. The AppImageUpdate mirror doesn't exist yet: you need to create it by setting up a code import, but that's the first step of Method 1 anyway, and you get to ignore subsequent steps.

Notes:

1. lp:libappimage on recipe line 4 is shorthand for https://code.launchpad.net/~appimage-maintainers/libappimage/+git/libappimage. It works because the repository at that URL has been set as the default libappimage repo on Launchpad. You could create a similar alias like lp:~appimageupdate for use on line 5 but you don't have to: the full URLs work fine.

2. I told the nest command to checkout specific commits of the libappimage (36691c47fc) and AppImageUpdate (b6cfe00a13), but you could checkout a branch name instead (e.g. stable or appimagelaucher) and that way you can control the build automatically on GitHub rather than by manually updating the recipe on Launchpad with new commit SHAs for the "nested submodules".

The advantage of Method 2 is you just need a code import and modified build recipe. You can avoid all the subsequent steps of creating Debian packaging, installing to a versioned folder, creating multiple recipes, and enabling builds for each new Ubuntu release.