dirs: use the right snap mount dir for the distribution #2845

Merged
merged 2 commits into from Feb 14, 2017

Conversation

Projects
None yet
3 participants
Contributor

zyga commented Feb 14, 2017

Stacked on #2844

Some distributions use /var/lib/snapd/snap as the place where snaps are mounted
so make this a dynamic runtime choice made on startup of snapd and other tools.

Signed-off-by: Zygmunt Krynicki me@zygoon.pl

zyga added some commits Feb 14, 2017

many: differentiate between "distro" and "core" libexecdir
Inside the core snap libexecdir is always /usr/lib/snapd but on the outside it
may be also /usr/libexec/snapd. In order for snap-confine and snap-exec to play
ball across the root filesystem transition we need to use the right path.

Signed-off-by: Zygmunt Krynicki <me@zygoon.pl>
dirs: use the right snap mount dir for the distribution
Some distributions use /var/lib/snapd/snap as the place where snaps are mounted
so make this a dynamic runtime choice made on startup of snapd and other tools.

Signed-off-by: Zygmunt Krynicki <me@zygoon.pl>

@zyga zyga added this to the 2.23 milestone Feb 14, 2017

+ DistroLibExecDir = filepath.Join(rootdir, "/usr/lib/snapd")
+ }
+
+ CoreLibExecDir = filepath.Join(rootdir, "/usr/lib/snapd")
@Conan-Kudo

Conan-Kudo Feb 14, 2017

Contributor

For now, I suppose this is fine, since we don't have support for different bases and core snaps yet, but just a fair warning that this assumption is not likely to stick around either...

@Conan-Kudo

Conan-Kudo Feb 14, 2017

Contributor

It occurs to me that you could test for the existence of /usr/libexec/snapd, and if it exists, use it, otherwise just fall back to /usr/lib/snapd. That's much simpler than trying to use crazy case statements to switch things around.

@zyga

zyga Feb 14, 2017

Contributor

For core that's a good assumption. For base that won't be a factor (I think).

As for the second advice I agree, I will look at making all the runtime checks comprehensive and not based on the os-release but rather on the important property at hand, I just wanted to land this quickly as it bears a lot of fruit.

@Conan-Kudo

Conan-Kudo Feb 14, 2017

Contributor

@zyga Like I said, for now the core snap libexecdir thing is fine, but once it becomes possible for me to make a Fedora Snappy Core using a core snap based from the build artifacts from Fedora infrastructure, that will not be valid anymore.

If the change to support this difference is trivial, I'd prefer to see it handled now rather than later, since you're already messing with this code.

@zyga

zyga Feb 14, 2017

Contributor

We will not do fedora snappy core, we will do a fedora base, the core will stay unique but it will not be used as the root for snap execution anymore. I think we are in agreement, it was just the naming that got confusing.

Anyway, aside from my comments above, it looks fine to me.

Contributor

Conan-Kudo commented Feb 14, 2017

@zyga Can you rebase this PR against master?

vosst approved these changes Feb 14, 2017

LGTM

@zyga zyga merged commit c5ee69f into snapcore:master Feb 14, 2017

5 of 6 checks passed

yakkety-amd64 autopkgtest finished (failure)
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
xenial-amd64 autopkgtest finished (success)
Details
xenial-i386 autopkgtest finished (success)
Details
xenial-ppc64el autopkgtest finished (success)
Details
zesty-amd64 autopkgtest finished (success)
Details

@zyga zyga deleted the zyga:runtime-snap-mount-dir branch Feb 14, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment