apk support in discover

changed milestone to %Apps

By Oliver Smith on 2020-03-22T02:37:24

added 1 deleted label

added help wanted label

mentioned in issue #12 (closed)

By Oliver Smith on 2020-03-22T02:40:35

Anything changed since then?

Not much, I'm too busy testing/merging MRs to have time for something else

By Alexey Min on 2020-03-22T20:53:38

mentioned in issue #561 (closed)

By Anjandev Momi on 2020-04-23T07:10:44

Simplified scheme of components and their interaction.

1. Implementation of libapk-qt

libapk-qt was supposed to be very simplified level of abstraction on top of apk-tools API which is hidden inside libapk.so (part of Alpine's apk-tools package). It should provide easy-to use, C++/Qt style methods to query packages database, add/remove packages and preform system upgrade.

First problem was that apk-tools does not have "stable API" and even libapk.so is not installed by apk-tools (no apk-tools-dev). So the solution for this was to use apk-tools as git submodule and embed apk.so into libapk-qt.so as static lib. Turned out that it also contains libfetch (from FreeBSD?) to perform network I/O ops.

Second problem is that apk headers are not supposed to be used from C++, so they cause compile errors (for example, some function parameters are named "new", which is reserved keyword in C++). I also have to apply this patch on top of apk-tools checkout just to make it compile.

Actually embedding apk.so into libapk-qt helped development a lot, I could use code navigation in QtCreator inside apk-tools to study its sources, and use source-level debugging with breakpoints.

2. Implementation of discover's APK backend

This turned out to be a larger task, and although I could create a simple proof-of-concept relatively quickly, there were many problems left.

First problem is that some package actions require root permissions to modify apk package database. So I had to additionally Use KAuth framework for that purpose. I added privileged kauth helper executable that is invoked by framework (internally using DBus) that actually performs package management tasks. So the picture above should be even more complicated, because now kauth helper actually uses libapk-qt, not discover apk backend itself.

Second problem is that Discover UI has various progress bars to inform user about progress of ongoing tasks, and libapk-qt interface was designed to be synchronous. For example you call system upgrade action API that corresponds to "apk upgrade" and function does not return until upgrade is finished. Discover was initially designed to interact with PackageKit, via PackageKit-Qt5 library, that is simple wrapper on top of packagekitd DBus interface:

So, by nature this DBus interface is asynchronous: you start operation (Transaction), receive progress updates, and then a signal when operation is finished. All communication over DBus, all hard work is done inside packagekitd by one of its backends.

apk has support for writing operations' progress into special pipe file (progress_fd), but I couldn't use it due to synchronous nature of libapk-qt API. So, to properly implement progress updates, new asynchronous API has to be designed in libapk-qt. It will run operations in background thread and will support Qt's signals/slots and progress updates!

=============== YOU (WE) ARE HERE ===============

By Alexey Min on 2020-06-11T20:13:47

And finally, third problem is (was?) lack of appstream data support, which results in no app icons, no categorization, ...

And metadata currently is faked (generated from APKBUILD package info):

What is particularly ugly here is that "Author:" field is taken from package's "Maintainer:" field

By Alexey Min on 2020-06-11T20:37:32

changed the description

By Alexey Min on 2020-06-12T12:06:00

discover_teaser-2020-07-29_04.05.50

This is update on aync operations and progress reporting (tested on large package krita)

Also a feature demo: repos URL configuring

By Alexey Min on 2020-07-30T02:38:57

This is after integration with appstream metadata

By Alexey Min on 2020-07-30T02:40:21

mentioned in issue #744 (closed)

By Alexey Min on 2020-09-19T21:14:12

With removal of alpinelinux-appstream-data from Alpine I'm not sure if this beautiful thingie is possble anymore (except on 3.12)

Alexey Min restore previous generator too
Cogitri Then we'd still have to maintain that, have a separate URL, have the storage and CPU time to run it etc.
I'd rather have Discover be able to download appstream data, the plugin for GNOME Software which does that is only a few hundred LoC
Cogitri more like only storage tbh
Cogitri https://gitlab.gnome.org/GNOME/gnome-software/-/blob/master/plugins/external-appstream/gs-plugin-external-appstream.c
Yup, the appstream data should be saved to $DIR/app-info/xmls/$FILE
Where DIR can be /usr/share or /var/cache or probably other things too in XDG_DATA_DIRS
GNOME Software installs it to /var/cache

https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/gnome-software/org.gnome.software.gschema.override

By Alexey Min on 2021-01-25T01:47:10

So what about the suggestion of making Discover able to download the appstream data? I don't know the codebase, but from distance it sounds pretty feasible.

By Oliver Smith on 2020-09-23T09:28:56

Of course we could download it somewhere, but to put it into place where appstream library can find it we'll need root rights (again), see

https://github.com/ximion/appstream/blob/master/src/as-pool.c#L96 :

/**
 * AS_SYSTEM_COLLECTION_METADATA_PATHS:
 *
 * Locations where system-wide AppStream collection metadata may be stored.
 */
const gchar *AS_SYSTEM_COLLECTION_METADATA_PATHS[4] = { "/usr/share/app-info",
							"/var/lib/app-info",
							"/var/cache/app-info",
							NULL};

By Alexey Min on 2020-09-27T17:29:45

Apparently there is a as_pool_add_metadata_location function, need to figure out if it works (AppStreamQt: https://github.com/ximion/appstream/blob/master/qt/pool.h#L119)

By Alexey Min on 2020-09-27T17:36:49

mentioned in issue #699 (closed)

By Oliver Smith on 2020-09-23T09:34:20

DiscoverNotifier support is not implmented yet (needs a backend plugin for that thing too), but this should provide "new distro release" notification, see #943 (comment 492514457)

By Alexey Min on 2021-01-24T06:19:35

removed help wanted label

mentioned in merge request !1881 (closed)

By Alexey Min on 2021-02-01T17:59:09

Initial support should land in !1881 (closed). After that, 2 things will be left to do:

better support for appstream IDs when searching for packages. This affects search, filtering on installed/featured pages and so on..
implement DiscoverNotifier support. This will provide tray icon with upgrades notification and new distro release notification

By Alexey Min on 2021-02-01T18:02:53

mentioned in issue #1384 (closed)

By Pablo Correa Gomez on 2022-01-11T23:06:05

What is the current state of this?

By Newbyte on 2023-06-28T11:42:53

If you have unbearable urge to close issues, we can close this one, IMO

By Alexey Min on 2023-06-28T12:12:08

Are you closing this because apk now is supported in Discover, or just because you don't plan to work on this any more?

By Newbyte on 2023-06-28T12:12:08

The issue is so old, it looks like it is about initial support of apk in plasma-discover. Initial support is done. But more work is needed.

It probably makes sense to make separate issues for remaining tasks, but I don't have motivation to track them all now

By Alexey Min on 2023-06-28T15:06:00

closed

added category::ui type::feature ui-plasma-bigscreen ui-plasma-desktop ui-plasma-mobile labels

apk support in discover

Child items ...

Activity

Simplified scheme of components and their interaction.

1. Implementation of libapk-qt

2. Implementation of discover's APK backend