Thank you very much for your work with the KDE snaps.
I do however have some reservations about them. Why pretty much any KDE snap is over 100 MB in size?
Do they not use a content snap, like the Gnome snaps.
Thank you very much for your work with the KDE snaps.
I do however have some reservations about them. Why pretty much any KDE snap is over 100 MB in size?
Do they not use a content snap, like the Gnome snaps.
I broke this out to a separate topic, because itās a new question.
Arguably itās off topic for this site, but it seems rude to punt you somewhere else when @scarlettmoore is actually here.
I thought Iād gather some data for this conversation. Itās rough, cobbled together with a hastily written shell script. But it may help.
for s in $(snap find kde | awk '{print $1}' | tail -n +2); do echo -n "$s: " && snap info $s | grep "latest\/candidate" | awk -F ' ' '{print $5}'; done | sort -h -t ':' -k2
kde-qt6-sdk:
kruler: 233kB
ktimer: 253kB
kmag: 385kB
yakuake: 593kB
killbots: 1MB
kigo: 2MB
sweeper: 2MB
kig: 6MB
kmousetool: 7MB
kpat: 17MB
krdc: 24MB
lokalize: 29MB
klettres: 42MB
skanlite: 68MB
parley: 115MB
kirigami-gallery: 126MB
ktouch: 127MB
kwordquiz: 127MB
knavalbattle: 144MB
kcolorchooser: 148MB
bovo: 149MB
kdebugsettings: 149MB
kiriki: 149MB
kjumpingcube: 149MB
ksnakeduel: 149MB
kspaceduel: 149MB
ksquares: 149MB
kubrick: 149MB
katomic: 150MB
kfourinline: 150MB
kmines: 150MB
konquest: 150MB
kreversi: 150MB
picmi: 150MB
blinken: 151MB
bomber: 151MB
klines: 151MB
kollision: 151MB
kdf: 152MB
klickety: 152MB
knetwalk: 152MB
palapeli: 152MB
granatier: 153MB
kmplot: 153MB
kbruch: 154MB
falkon: 155MB
kbounce: 165MB
kgeography: 166MB
kiten: 166MB
kbreakout: 168MB
kshisen: 169MB
kmahjongg: 170MB
kanagram: 172MB
kcalc: 172MB
ark: 181MB
labplot: 185MB
kteatime: 192MB
spectacle: 192MB
kblackbox: 193MB
kturtle: 193MB
okular: 196MB
artikulate: 197MB
kwave: 197MB
konqueror: 202MB
kalgebra: 206MB
dolphin: 207MB
okteta: 207MB
kdiamond: 212MB
cervisia: 216MB
gwenview: 223MB
minuet: 223MB
rocs: 226MB
neochat: 228MB
kde-dev-utils: 230MB
umbrello: 231MB
skrooge: 235MB
kolourpaint: 237MB
peruse: 238MB
ksirk: 246MB
gcompris: 253MB
step: 253MB
kapman: 266MB
kblocks: 266MB
ksudoku: 266MB
kgoldrunner: 270MB
konversation: 272MB
dragon: 273MB
kate: 276MB
kompare: 303MB
ktuberling: 319MB
kde-qt6-core22: 326MB
kde-qt6-core22-sdk: 328MB
kstars: 336MB
digikam: 393MB
kdenlive: 474MB
itinerary: 677MB
kalzium: 684MB
kdevelop: 764MB
cantor: 1GB
Hope thatās useful
Iām sure @scarlettmoore would appreciate the help with people identifying how to optimise these!
I have no idea if this is the right way to go about it, or helpful in any way, butā¦
I tried looking at the differences between the snapcraft.yaml
files of a small KDE snap (picked ktimer
), and of a big KDE snap (picked knavalbattle
), and Iām wondering if the āstage-packages
ā are contributing somehow?
ktimer
has no stage-packages in the parts section, while knavalbattle
has libasound2-data
and libasound2-plugins
listed under stage-packages:
Neither of those packages are enormous on their ownā¦but libasound2-plugins
looks like it has a pretty gnarly dependency tree, especially once it hits libavcodec60
:
$ apt show libavcodec60
...
Installed-Size: 15.2 MB
Depends: libaom3 (>= 3.2.0), libavutil58 (= 7:6.0-6ubuntu1), libc6 (>= 2.35), libcairo2 (>= 1.2.4), libcodec2-1.2 (>= 1.2.0), libdav1d6 (>= 0.9.0), libglib2.0-0 (>= 2.12.0), libgsm1 (>= 1.0.18), libjxl0.7 (>= 0.7.0), liblzma5 (>= 5.1.1alpha+20120614), libmp3lame0 (>= 3.100), libopenjp2-7 (>= 2.0.0), libopus0 (>= 1.1), librav1e0 (>= 0.5.1), librsvg2-2 (>= 2.14.4), libshine3 (>= 3.1.0), libsnappy1v5 (>= 1.1.10), libspeex1 (>= 1.2~), libsvtav1enc1 (>= 1.6.0+dfsg), libswresample4 (>= 7:6.0), libtheora0 (>= 1.0), libtwolame0 (>= 0.3.10), libva2 (>= 2.9.0), libvorbis0a (>= 1.1.2), libvorbisenc2 (>= 1.1.2), libvpl2 (>= 2023.3.0), libvpx7 (>= 1.12.0), libwebp7 (>= 1.2.4), libwebpmux3 (>= 1.2.4), libx264-164 (>= 2:0.164.3095+gitbaee400), libx265-199 (>= 3.5), libxvidcore4 (>= 1.2.2), libzvbi0 (>= 0.2.35), zlib1g (>= 1:1.2.0)
And when I look at my system after installing both, sure enough, knavalbattle
has a much larger /snap/-snap name-/current/usr/lib
directory than chromium
, even though I would assume chromium
āshouldā be a much larger package? Now, I donāt know if all those A/V libraries are critical to knavalbattle
- that might be unavoidable for how the app works and for whatās included in
Now, kcolorchooser
didnāt have stage-packages specified in its snapcraft.yaml
file, however, in comparing it to ktimer
I did notice that kcolorchooser
didnāt have kde-neon
listed in the `cleanup section:
From the reading Iāve done, it sounds like that might be contributing to the size of kcolorchooser
by leaving behind the majority of the āframeworkā-type packages in the final snap itself?
Sorry if all this is a waste of space on here, hopefully it might be useful to someone?
Discussions about snap packaging should really move over to the appropriate forum at:
I dont think the global Community category here on discourse.ubuntu.com is the right placeā¦
Iāve made a post on snapcraft forum.
But arenāt snaps āuniversalā? are they different from Gnome and KDE now?
The individual snaps will be universal, if Johnās suspicion is correct about the ALSA plugins, the majority of snaps donāt directly access ALSA and so the ALSA components donāt deduplicate with the content snaps because the content snap doesnāt have it.
It might be that those snaps donāt need direct ALSA access or the ALSA ā Pulseaudio wrapper and it might be possible to trim them, but since itās on the Snapcraft forums now, probably better to evaluate over there :).
Snaps are universal, not sure what you mean with ādifferent from GNOME and KDEā, but technical discussions about improvement in packaging surely do not fit into a forum category that is designed for discussion about general community matters
Reading the first post it seems to understand that KDE snaps are different from Gnome snaps.
They arenāt reallyā¦
both use content/platform snaps for shared libs, but while the gnome one has a whole team of full paid developers working on it, kde has Scarlettā¦ more people helping with it and moving things between the snaps will surely improve the situation and drop sizes