Manual review of plasma-core24-desktop

store-requests
1

I’d like to request the use of external symlinks for the plasma-core24-desktop content snap on the store, which is currently held up by manual review.

Some information about the snap:

  1. The snap name is registered by the KDE account.
  2. The snap source is managed at https://invent.kde.org/neon/snap-packaging/plasma-core-desktop . It is a content snap with the binaries necessary to enable a KDE Plasma session.
  3. The external symlinks are mostly here to be able to expose the right targets and services aliases to systemd to allow the proper startup of a KDE Plasma session.
  4. The snap is not intended for wide use by many snaps: it is intended to be only used by the plasma-desktop-session snap and maybe a future sddm snap.

Thanks in advance.

2

Sorry to bother, could anyone look into this request please? @cav you helped with similar requests in the past, maybe you could do some magic again? :slight_smile:

3

Hey @kottens

Sorry for the delay. I’m not completely sure to understand how this interaction is expected to work, but external symlinks are rarely granted.

@jamesh could you provide your opinion about this request?

Thanks

4

Right, let me give a bit more context:

  • we currently can’t express or import systemd targets, so this content snap is coming with them
  • said targets refer to services with well known names
  • snapd will generate service files using its own naming rules (services described in the plasma-desktop-session snap)
  • so in the content snap we also provide symlinks since it’s the way to provided alias names to systemd (this helps reconcile between targets and snapd generated services)

Hope it helps understand what they are for.

5

So I’ve looked through a build of @kottens’s snap with respect to the symlink problems. There seem to be two classes here:

  1. symlinks to binaries and desktop files (e.g. $SNAP/usr/bin/lookandfeeltool -> /usr/bin/plasma-apply-lookandfeel).
  2. symlinks to systemd services.

For (1), these will be broken links when the snap is mounted as a content snap since the files they point at do not exist in core24. They should be converted to relative symlinks, which should fix those automated review issues.

For (2), this is part of some transitional code we have in the Ubuntu Core Desktop base snap to support multiple desktops:

There’s three types of symlinks here:

  • Symlinks to /dev/null to disable a service. From the look of the systemd source, it uses a null_or_empty_path() helper here, so empty files would be equivalent to these symlinks.

  • Symlinks from non-snap service names to /etc/systemd/user/ paths for the service files snapd would write out for the plasma-desktop-session snap. From the look of it, these are here to add foo.service.d/override.conf files to make those services part of graphical-session.target. There are also a few plasma-*.target files that reference these named services. From the look of it, this could all be done without the symlinks:

    • Apply the PartOf overrides to the snap.plasma-core-desktop.* service names.
    • Have the targets depend on the snap.plasma-core-desktop.* service names.

    If the Plasma session code is only concerned with the plasma-*.target units, then it shouldn’t matter what the service units are called.

6

Didn’t really want to modify the targets to be honest but fair enough. I did that and it went through the automated review just fine (unsurprisingly).

2 Likes