Dockerfile与容器内执行dpkg行为不一致的技术问询

嗨，这个问题我碰到过好几次，主要有几个可能的原因，你可以逐一排查：

1. *.deb 的Shell展开顺序差异 #

Docker的RUN指令默认使用sh Shell，而你手动进入容器后大概率用的是bash，这两个Shell对通配符*.deb的排序规则可能不一样。

比如你的somedebianrepo里有依赖包lib-dep.deb和主包lib-main.deb：

• 在sh里，通配符展开可能是lib-main.deb在前，lib-dep.deb在后，执行dpkg -i时先装主包，此时依赖包还没安装，就会触发依赖错误；
• 而在bash里，排序可能反过来，先装依赖包，主包就能正常完成配置。

解决方法：

• 显式指定安装顺序，避免通配符的不确定性：

  RUN dpkg -i /basedir/lib-dep.deb /basedir/lib-main.deb
  

• 或者在RUN里强制使用bash执行命令：

  RUN bash -c 'dpkg -i /basedir/*.deb'
  

2. Docker构建缓存导致的旧包残留 #

如果之前你构建过镜像，Docker可能缓存了COPY somedebianrepo/*.deb /basedir/这一层。要是你之后更新了somedebianrepo里的deb包（比如新增了依赖包），Docker不会自动重新执行COPY步骤，导致构建时用的还是旧的不完整的deb包集合，从而触发依赖错误；而你注释掉RUN重新构建时，可能刚好触发了缓存失效，容器内的包是完整的，所以手动执行没问题。

解决方法：

• 构建时加上--no-cache参数，强制重新执行所有步骤：

  docker build --no-cache -t your-image .
  

• 或者修改Dockerfile，在COPY前添加一个无关的注释或环境变量，让Docker认为这一层需要重新构建。

3. dpkg的临时状态差异 #

Docker的RUN指令是在隔离的临时容器中执行，执行完成后会将容器文件系统状态提交为镜像层。有时候dpkg在安装过程中会留下临时状态文件，这些文件在镜像提交时可能被清理或未正确保留；而手动执行时，容器是持续运行的，dpkg的状态文件能正常读写，从而避免了依赖检测的问题（这种情况比较少见，但也有可能）。

解决方法：

• 在RUN指令中加上apt-get -f install -y自动修复依赖：

  RUN dpkg -i /basedir/*.deb || apt-get -f install -y
  

  这样即使dpkg安装时触发依赖错误，apt会自动从源中安装缺失的依赖包（前提是镜像的apt源配置正常）。

内容的提问来源于stack exchange，提问作者Marvin