Usability regression with package dependencies

niemeyer · June 26, 2019, 9:56am

Hello all,

This week I’ve created a new snap using core18 as a base, and the experience was both great and painful at the same time.

It was great because I’ve managed to build the software using the cmake plugin on the very first try! Felt so good to see the software packaged by just pointing to the repository and have everything snapped out so easily.

On the other hand, it was also very painful as I had to fight for a long time trying to pick up every single package dependency to put on stage-packages. We urgently need a solution for this so that people don’t need to be doing this by hand. To be clear, the problem isn’t the fact I need to list these dependencies explicitly, but that I have to figure out by myself how to find out all the dependencies that I need to put in.

Am I overlooking something, or is that the status quo indeed?

What is the plan for fixing that?

Thanks!

ogra · June 26, 2019, 10:14am

while i think it is really hard to get all the runtime dependencies for externally called binaries in some automatic way, for libs this sounds actually solvable.

i.e. by auto-filling stage-packages for each build-package you use … typically a libfoo-dev package depends on libfoo so there is a way to reverse-resolve this connection and to pre-fill stage-packages (i.e. snapcraft --generate-deps) with them …

runtime binaries are a different kind though … you’d have to exec the binary snap and make guesses based on error messages to then pull in missing packages.

due to the self contained nature of snaps stage-packages are often a combo of both.

niemeyer · June 26, 2019, 10:18am

There’s no reason to guess based on package names… we know exactly which binaries are going into the snap, we know which libraries these are linked with (assuming non-dlopen), and we know which packages contain these libraries.

We did that before, and we switched to requiring the list of included packages to be explicit, which is fine by itself. We just cannot expect people to be doing that process entirely by hand now.

sergiusens · June 27, 2019, 2:08pm

This is true, the experience is more complicated now and we intend to fix it with an integrated story that takes into account any library provided by use of the content interface.

We started some conversation around this last week during our standup, I will keep you in the loop.

niemeyer · June 27, 2019, 4:31pm

This is completely unrelated to the content interface. If I’m trying to snap some software which links to libraries, I don’t need the content interface. This needs to be addressed as a matter of urgency as it’s making the use of the new bases extremely painful.

Can we please have a call early next week on this?

Meanwhile, please try the following to prepare for the call: snap this software:

https://github.com/xournalpp/xournalpp

Don’t use the upcoming gnome extension, but rather do it by hand to understand the general experience of people that will be snapping software that is not covered by our extensions.

Please try to get the snap working before our call next week, and write down notes as we go so we can use them during the call.

sergiusens · June 28, 2019, 1:20pm

I have a working snap, as I tried to register it, I noticed Ken has one too (without using extensions), https://snapcraft.io/xournalpp.

The problem of snaps based out of GTK being hard is well know and has been discussed at length between the Advocacy and Desktop teams, this gave origin to the desktop parts and plans are in place to improve this, we can discuss this over the meeting.

The application you chose is also using alsa, another pain point for anyone using that for which we proposed to create an extension and was rejected as being too specific during the January Product Roadmap.

niemeyer · June 28, 2019, 1:22pm

Where are the notes?

sergiusens · June 28, 2019, 1:47pm

Notes:

The experience of snapping a GTK application is similarly complicated as prior to bases.
Missing libraries are not automatically pulled in from the host anymore, instead a list of what is missing is displayed, this may be too long a list for a big stack, library pulling might make sense to re-enable (explicitly or implicitly TBD) taking into account that some of these libraries may be provided by use of a snap leveraging the content interface Simple trick to reduce size and startup time of GNOME-based snaps
GTK requires domain specific knowledge which the desktop parts encode (https://github.com/ubuntu/snapcraft-desktop-helpers), without that it requires one to be a GTK expert.
Most of the GTK/GNOME tweaks are related to libraries living within /snap/…/usr and not / … some of these things could be just patched upstream or in the Ubuntu archive to consider snaps out of the box.
ALSA is complicated, an extension would be ideal.
overuse of stage-packages when using the content interface brings in duplicate content as there is no easy way to cut the dependency chain on stage-packages (this is why I built alsa, libsndfile and libportaudiocpp from source).

niemeyer · June 28, 2019, 2:06pm

Where are the notes of creating this specific snap? What specifically went wrong, when, what did you to do solve it, etc, for all the steps?

Which list? How does it look? Can we please see a screenshot of that?

What steps did you actually have to go through?

…

I’m not looking for the snap ready in this case, and I knew Ken already had it ready. I’m interested in your perspective on the experience everyone has to have when creating snaps that don’t happen to match the exact sweet spot we have for the one extension we are working on.

dylanetaft · June 28, 2019, 3:36pm

I started using snap recently and was surprised by this a bit.

Microsoft App-V and VMWare Thinapp do file diffs on the filesystem and just pull everything in and give you a list at the end of what was pulled in. There a reason why Snapcraft doesn’t go that route?

sergiusens · June 28, 2019, 8:03pm

This is the behavior when you do not use the base keyword, we have a couple of issues with that implementation that we wanted to better implement, those are:

if the snap you were creating were to make use of the content interface to provide additional artifacts at runtime, you would still get them in your snap (duplication)
we did not have a story for consistent build environments (we do now), which lead to many support issues.
we did no record origin of where the file came from for USN notifications (https://usn.ubuntu.com/).

It will be coming back though, sorry for the inconvenience

sergiusens · June 28, 2019, 10:37pm

Those were the notes on the specific snap, I did not write step-by-step notes, I cannot do that again as I will be tainted by knowing where to go (I already was before hand as I knew of the existence of the content interface and a solution to alsa), but I will try and reflect them as best I can.

I cannot be through

Cloned the project
Ran snapcraft init
Changed the default part name to main
Looked at the project’s build system, found a matching snapcraft plugin, cmake (the default snapcraft.yaml template guided me there).
Looked at the project’s build dependencies and added equivalent build-packages.
Ran snapcraft prime --use-lxd
Got a long list of missing libraries. Noticed most were from a GTK stack, so I added

plugs:
  gnome-3-28-1804:
    interface: content
    target: $SNAP/gnome-platform
    default-provider: gnome-3-28-1804

Given it was gnome and I knew this would require a lot of runtime setup I preemptively added from former wiki parts which provides a desktop-launch script and has knowledge about the content interface:

  desktop-gnome-platform:
    source: https://github.com/ubuntu/snapcraft-desktop-helpers.git
    source-subdir: gtk
    plugin: make
    make-parameters: ["FLAVOR=gtk3"]
    build-packages:
    - libgtk-3-dev
  gtk-3-themes:
    interface: content
    target: $SNAP/data-dir/themes
    default-provider: gtk-common-themes
  icon-themes:
    interface: content
    target: $SNAP/data-dir/icons
    default-provider: gtk-common-themes
  sound-themes:
    interface: content
    target: $SNAP/data-dir/sounds
    default-provider: gtk-common-themes

I ran dpkg -S against the remaining libraries missing and added those as stage-packages in a new part using the nil plugin and stage-packages entries (liblua5.3-0 libpoppler-glib8 libportaudio2 libsndfile1 libxml2 libzip4 libasound2 libasound2-plugins), setting an after: [deps] in the main part so that the libraries are found during the missing library notification.
I ran snapcraft try --use-lxd.
Saw the reduced output of still missing files (provided by the above content snap):

The 'main' part needs the following libraries that are not included in the snap or base: 
usr/lib/x86_64-linux-gnu/libXcomposite.so.1
usr/lib/x86_64-linux-gnu/libXcursor.so.1
usr/lib/x86_64-linux-gnu/libXdamage.so.1
usr/lib/x86_64-linux-gnu/libXfixes.so.3
usr/lib/x86_64-linux-gnu/libXi.so.6
usr/lib/x86_64-linux-gnu/libXinerama.so.1
usr/lib/x86_64-linux-gnu/libXrandr.so.2
usr/lib/x86_64-linux-gnu/libatk-1.0.so.0
usr/lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0
usr/lib/x86_64-linux-gnu/libatspi.so.0
usr/lib/x86_64-linux-gnu/libcairo-gobject.so.2
usr/lib/x86_64-linux-gnu/libdatrie.so.1
usr/lib/x86_64-linux-gnu/libepoxy.so.0
usr/lib/x86_64-linux-gnu/libgdk-3.so.0
usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0
usr/lib/x86_64-linux-gnu/libgraphite2.so.3
usr/lib/x86_64-linux-gnu/libgtk-3.so.0
usr/lib/x86_64-linux-gnu/libharfbuzz.so.0
usr/lib/x86_64-linux-gnu/libpango-1.0.so.0
usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0
usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0
usr/lib/x86_64-linux-gnu/libthai.so.0
usr/lib/x86_64-linux-gnu/libwayland-client.so.0
usr/lib/x86_64-linux-gnu/libwayland-cursor.so.0
usr/lib/x86_64-linux-gnu/libwayland-egl.so.1
usr/lib/x86_64-linux-gnu/libxkbcommon.so.0
These dependencies can be satisfied via more stage-packages, more parts, or content sharing.
You can now run `snap try /home/sergiusens/projects/crafters/xournalpp/prime`.

Saw that what I wanted to launch was under bin/xournalpp so I added an apps with command: bin/desktop-launch $SNAP/bin/xournalpp entry with proper plugs entries after reading through https://docs.snapcraft.io/desktop-interfaces
Alsa failed to load, on snap try and running I got ALSA lib control.c:1373:(snd_ctl_open_noupdate) Invalid CTL hw:0 xournalpp: src/hostapi/alsa/pa_linux_alsa.c:1453: BuildDeviceList: Assertion devIdx < numDeviceNames’ failed.. Recalled Advocacy claimed that alsa was complicated and would be good to have an extension for and referring to a forum post so I did a search https://forum.snapcraft.io/search?q=alsa and found https://forum.snapcraft.io/t/reusable-alsa-lib-part/3556 ... added that as a specific part and and removed alsa stage-packagesfrom thedeps` part.
Ran successfully
Found a desktop file, added a desktop entry to the apps entry pointing to that path.

dylanetaft · June 29, 2019, 5:31pm

I’m doing something similar, but using bases + multipass here instead of lxc.
build-packages: [parted, xsltproc,libxml2-utils,pkgconf,libp11-kit-dev,libnetcf-dev,libnl-3-dev,libnl-route-3-dev,libxml2-dev,libdbus-1-dev,libsasl2-dev,libssh-dev,libudev-dev,libpciaccess-dev,libyajl-dev,open-iscsi,libdevmapper-dev,libparted-dev,zfsutils-linux]
stage-packages: [parted, xsltproc,libxml2-utils,pkgconf,libp11-kit0,libnetcf1,libnl-3-200,libnl-route-3-200,libxml2,libdbus-1-3,libsasl2-2,libssh-4,libudev1,libpciaccess0,libyajl2,open-iscsi,libdevmapper1.02.1,libparted,zfsutils-linux]

Reviewing ./configure output from autotools and then finding appropriate dev packages required for building a piece of software I’m trying to package.
Then to my dismay, the libs aren’t pulled in automatically, and Ubuntu doesn’t use the same package names often, so I had to manually identify what packages in the Ubuntu repo contain the associated libraries. Can’t just include the dev libs in stage as often .deb packages overwrite eachother’s files and snap doesn’t like that.

niemeyer · July 2, 2019, 10:30am

To be clear, it won’t be coming back, per our meeting yesterday. The change to not magically introduce new packages and runtime dependencies without acknowledgement from the package maintainer seems like a good one still. It’s the lack of support for that workflow that feels like an issue, and we can address one without giving up on the other.

sergiusens · July 16, 2019, 4:18am

This is not final and the messaging is open for change, this is the scenario for already having stage-packages defined in the part: