Why are some KDE snaps large?

snapcraft
1

As per suggestion by ogra I’ve made this topic here where it is more apropriate.

3 Likes
2

Thanks for moving over here…

One thing you should look at (together with @scarlettmoore I guess) is to move more libs into the kde content snaps by identifying commonly used ones, that might significantly reduce the sizes of the individual app snaps

1 Like
3

Yes that would definetly help.

Also for anyone looking here the linked topic in ubuntu discourse has some posts to check out.

1 Like
4

Hi all, Yes I am aware of the sizes. I have found some issues where our builds are bringing in duplicate libraries and have already implemented a cleanup stage on our next release. This will reduce the file sizes significantly. We are also adding the missing frameworks to the content pack that caused the issue in the first place. The other issue I have not solved is optional data packs that I currently bundle with the snaps that could possibly be separated out into content packs, but they aren’t really useful for other snaps so that seemed like overkill. I am open to ideas and help… Thanks, Scarlett

7 Likes
5

Have you looked at the @johnandmegh post in the ubuntu discourse?

2 Likes
6

I don’t have any real, hands-on knowledge so take anything I was poking around at with a billion grains of salt - on the other hand, if there’s something that’s on the right track and it just needs someone to scan through what’s out there on KDE Invent and plow through some edits, I’m happy to help there.

Thanks,

4 Likes
7

Thank you, that was super helpful.

1 Like
8

I think you are on to something with the alsa. Possibly legacy cruft. I have to do some testing before removing as I do recall having issue with sound on some apps. I will let you know if I need help purging these dependencies. Thank you for your insight.

2 Likes
9

I do wish we could make a tidy snippet to get alsa working in modern snaps. Currently, we tend to cargo-cult in a bunch of yaml, which may or may not work. Sometimes, snaps launch and there’s no audio until the second launch. It’s all a bit messy. I don’t know what the solution is, and I appreciate that ALSA is “Ye olde” sound technology. Sadly, many applications still use it.

1 Like
10

I don’t know about raw ALSA access and to be quite frank I’m coming from a position of “This works for me” and not “This is expert opinion” but…

For stuff where the Alsa → Pulse wrapper works, the absolute minimal needed setup is:

  1. A config file at a known location (E.G the KDE Content snaps)
pcm.!default {
        type pulse
        fallback "sysdefault"
        hint {
                show on
                description "Default ALSA Output (currently PulseAudio Sound Server)"
        }
}
ctl.!default {
        type pulse
        fallback "sysdefault"
}

  1. These stage packages (again, in the content snap)

    • libasound2
    • libasound2-plugins
    • libpulse0 (which already exists)

  2. This layout:

layout:
  /usr/lib/$SNAPCRAFT_ARCH_TRIPLET/alsa-lib:
    bind: $the_content_snap
  1. This environment variable

ALSA_CONFIG_PATH: $CONTENT_SNAP_LOCATION

I’d imagine all 4 of these can be done with the KDE-Neon extension to become automatic.

Of course, testing testing; does this breaks things that DO require direct ALSA access & etc.

But it’s a much technically simpler approach than other approaches I’ve seen (But for what it’s worth, I’d minimalised the work Lucy had done with her ALSA Mixins work and wouldn’t have had a clue if not basing on her project).

And since it uses layouts, it won’t work on classic (Unless layouts get added to classic, which was apparently possible but not implemented yet), so maybe there’s some more thought required on that specific point and might be why other approaches differ? Mind. classic snaps don’t have sandboxing so the ALSA access is a mooter point there anyway.

I’ve never had a problem or report on any of the snaps that I’ve used this on.

If the dependency trees are small enough, it could be worth making an extension just for them? E.G alsa-wrapper or generically audio. They’d probably need to be versioned for each base snap release but that’s how that usually goes anyway, that way people could get easy working audio without overloading Gnome/KDE/Others.

1 Like