On Thu, Oct 20, 2016 at 8:18 PM, Dustin Kirkland <kirkl...@canonical.com>
wrote:
> > Because the docker.sock path is hardcoded in a lot of images, this snap
> > conflicts with docker debs, so make sure you remove them first:
> > sudo apt purge docker docker-engine
>
> Hmm, that feels like something Snaps should learn to express as a
> declaration, right? Surely if we're successful in moving more
> applications, like Docker, from debs to snaps, our users would
> appreciate a kindly mechanism to
>
It's actually something that Docker upstream should get support for IMO;
not a Snap issue.
Basically, a lot of scripts/container images/docs hardcode this arg:
-v /var/run/docker.sock:/var/run/docker.sock
and then expect to find /var/run/docker.sock from inside the container.
(There are of course variations and slight differences on top)
This means we want the Docker snap to listen there, but then the .deb can't
listen there too.
IMO a cleaner approach would be for docker to have a
--expose-docker-socket-inside-container flag (albeit shorter :-).
Alternatively, I guess we could filter command-line arguments and remap
them, but it's start getting tricky – just like it's a bit tricky to know
which docker you mean when you run "docker" and that might pick up either
the /snap/bin/ one or the /usr/bin/ one.
> Very nice. What's the ETA on snap-declaration?
>
(have to check on that; it's either just an admin thing or "soon")
> Any blockers for s390x?
>
We need an OS snap for this arch first, and we don't have this ATM;
maintaining a .deb might be less work – not sure.
- Loïc
--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snapcraft
