so I’ve noticed a bit of a problem with how content snap use currently works.
For KDE software we have a content snap which contains all our core frameworks (priming runtime files/libraries only). Out of the stage directory we then create a tarball which acts more or less as SDK to build against the content snap.
For example an app’s snap file might then look like this:
parts: kde-frameworks-5-dev: plugin: dump prime: - "-*" source: https://..../kde-frameworks-5-dev_amd64.tar.xz application: after: [kde-frameworks-5-dev] plugin: cmake stage-packages: [foobar] source: ...
This is mostly alright. BUT. If the application needs to stage additional packages this can easily end in a mess. If the files between the dev tarball and the staged packages are different.
For example consider the following chain of events:
- March 1: content snap + dev tarball get built. dev tarball contains /libfoobar.so
- March 2: libfoobar package update gets released
- March 3: application snap wants to build with dev tarball and needs to stage package which depends on libfoobar. as a result libfoobar is also pulled in as well. the dev part gets staged and with it /libfoobar.so. when the app part gets staged snapcraft will error out since the /libfoobar.so staged by the dev part will be different from the /libfoobar.so staged by the application part (since it is older)
I’ve kinda hacked around the problem by implementing my own variant of stage-packages which can exclude packages. https://github.com/blue-systems/pangea-tooling/blob/master/nci/snap/plugins/x-stage-debs.py
This does seem fairly meh though, doesn’t work all that well for humans using it, and is an additional difference one has to think about when using the content snap.
Any thoughts on how to deal with this natively?