Docker in DebianCurrent Working Directoryhttp://current.workingdirectory.net/posts/2017/docker-in-debian/Current Working Directoryikiwiki2018-04-30T13:51:57Zusing equivs?http://current.workingdirectory.net/posts/2017/docker-in-debian/comment_1_a9530383b1e692db98680e2412834a82/dkg [id.mayfirst.org]2017-10-11T13:21:12Z2017-10-11T02:10:46Z
<p>rather than editing debian/control by hand, maybe it would be better to use <code>equivs</code> to make a stand-in package that sets up a Provides: relationship.</p>
<p>See <a href="https://manpages.debian.org/stable/equivs/equivs-control.1.en.html">equivs-control(1)</a> and <a href="https://manpages.debian.org/stable/equivs/equivs-build.1.en.html">equivs-build(1)</a> from <a href="https://tracker.debian.org/pkg/equivs">the "equivs" package</a>.</p>
<p>i did <a href="https://bugs.debian.org/876761">a similar workaround for a broken dependency on ipython3</a>.</p>
Problem is: provides.http://current.workingdirectory.net/posts/2017/docker-in-debian/comment_1_091f38f31fe18f905ea93e532a559d12/jamie [id.mayfirst.org]2018-04-30T13:51:57Z2017-10-11T13:41:33Z
<p>Thanks for that type dkg. It helped me re-think the problem: rather than seeing the problem as an incorrect dependency in docker.io and containerd, the problem is with docker-runc not <code>provide</code>ing runc.</p>
<p>In any event, the debian package maintainers <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877329#101">seem to have gone a different direction</a> and are uploading a docker-runc and docker-containerd package and will ensure docker.io depends on those instead of the runc and containerd packages.</p>
<p>Should be sorted out shortly. I hope these make it into testing and then stretch-backports.</p>