docs/snapcraft-syntax.md should explicitly name the conditions under which a file is expected to end up in stage/ and snap/

[Björn Michaelsen]

https://github.com/ubuntu-core/snapcraft/blob/master/docs/snapcraft-syntax.md currently says:
- stage-packages (list of strings) A list of Ubuntu packages to use that would support the part creation.

This is vague and leaves unclear, under which conditions files from these packages (or their dependencies) can be expected into end in the final snap (that they _can_ end up in snap somehow is implied by the different description of build-packages explicitly denying that for those).

E.g. having

stage-packages:
  - libxml2-dev
snap:
  - usr/lib/x86_64-linux-gnu/*
  - usr/include/libxml2/*

results in neither of:

 usr/include/libxml2/libxml/parser.h
 usr/lib/x86_64-linux-gnu/libxml2.so

to end up in the snap, while only the second ends up in the stage/ dir. (on snapcraft 2.2.2/xenial)

[Björn Michaelsen (bjoern-michaelsen)]

Same with for example:
 stage-packages:
    - libnss3
  snap:
    - usr/lib/x86_64-linux-gnu/lib*

Doing a 'ls stage/usr/lib/x86_64-linux-gnu/lib* |grep nss|wc -l' find 8 matches, yet 'ls snap/usr/lib/x86_64-linux-gnu/lib* |grep nss|wc -l' says there is no such file or dir ...

[Björn Michaelsen (bjoern-michaelsen)]

So it seems snap is populated from install only. Im working around this right now by copying from stage/ to install/ in the Makefile, but I cant imaging this to be the best practice: After all there is this "build-packages" and "stage-packages" destinction. What is it good for, if the latter still need to be copied around manually?

[Sergio Schvezov (sergiusens)]

- usr/lib/x86_64-linux-gnu/* not including libxml may as well be a bug.

- the propagation mechanism is installdir -> stagedir -> snapdir
- the source of propagation is always installdir for each part to easily detect conflicts between parts propagating the same file;
- for one part to see what the other did it has to build "after" the part it depends on (installdir is a private space for the part).

[Sergio Schvezov (sergiusens)]

Can we have a snapcraft.yaml that exhibits the issue please as it is hard to follow the description of the issue.

[Björn Michaelsen (bjoern-michaelsen)]

https://git.launchpad.net/~bjoern-michaelsen/df-libreoffice/+git/libreoffice-snap-playground/tree/?h=xenial has an example.
At:
 https://git.launchpad.net/~bjoern-michaelsen/df-libreoffice/+git/libreoffice-snap-playground/tree/libreoffice-build/Makefile?h=xenial#n34

the binaries are copied into ./install so that they end up in the .snap. Leaving that out results in missing libs in the resulting snap obviously.

[Leo Arias (elopio)]

Hello Björn! Sorry for the laaate reply.

I used this snapcraft.yaml: http://paste.ubuntu.com/24210431/
And got the two files in the snap:

ubuntu@juju-07fb34-remote-devel-0:/tmp/test$ ls prime/usr/include/libxml2/libxml/parser.h
prime/usr/include/libxml2/libxml/parser.h
ubuntu@juju-07fb34-remote-devel-0:/tmp/test$ ls prime/usr/lib/x86_64-linux-gnu/libxml2.so
prime/usr/lib/x86_64-linux-gnu/libxml2.so

Is this still a problem for you?

[Launchpad Janitor (janitor)]

[Expired for Snapcraft because there has been no activity for 60 days.]