在Ubuntu中通过Puppet安装open-vm-tools; 什么是小恶？

在一个理想的世界里，configurationpuppet来安装open-vm-tools应该是这样简单的：

 class vm-tools { package { 'open-vm-tools': ensure => installed } package { 'open-vm-dkms': ensure => installed } } 

但是，这开辟了一个丑陋的依赖性蔓延的jar头; 它会安装X，这显然不属于服务器。 从Ubuntu 10.04开始，这些软件包最终推荐使用GUI工具的open-vm-toolbox软件包：

 # apt-cache depends open-vm-dkms open-vm-dkms Depends: dkms Depends: make Suggests: open-vm-toolbox Recommends: open-vm-tools # apt-cache depends open-vm-tools open-vm-tools Depends: libc6 Depends: libfuse2 Depends: libgcc1 Depends: libglib2.0-0 Depends: libicu44 Depends: libstdc++6 Recommends: open-vm-source Recommends: open-vm-toolbox Recommends: ethtool Recommends: zerofree 

build议的软件包总是默认安装。 安装描述为“CLI工具”的软件包时，默认情况下安装X依赖关系显然是不可取的。

针对Debian的function请求立即被拒绝，但是在Ubuntu中没有冷静的头脑 。 看起来在上周内，人们已经认识到这是一个不明智的变化 ，但是直到下一个LTS发布之前，这是没有任何帮助的。

• 木偶文件源可以来自Web服务？
• 相同的类/模块/ orwhateveritis多次
• 伪装代理证书validation失败
• Puppet或Chef是否适合在多租户环境中pipe理非常基本的服务器configuration？
• 如何让傀儡停止在清单中的第一个错误？

使用--no-install-recommends选项在命令行中很容易禁用安装推荐软件包的行为，但是通过puppet不支持这样做，而且要求这种支持的票据 混乱 不堪 3年。

另一种select是通过apt.conf在整个系统中禁用推荐的软件包，这是对软件包行为的巨大改变，其影响远远超出我的apt.conf 。

我已经放弃了这种懒惰的方式;

 exec { 'open-vm-tools install': command => '/usr/bin/apt-get install -y --no-install-recommends open-vm-dkms open-vm-tools', creates => '/usr/lib/open-vm-tools', } 

但这显然是“做错了” 。 我是否错过了一些可以使它们按照预期的方式工作的东西，或者这是这个问题最好的解决办法？

 package { [ "open-vm-tools", "open-vm-dkms" ]: ensure => installed, provider => apt, } 

 package { [ "open-vm-tools", "open-vm-dkms" ]: ensure => installed, provider => aptitude, require => File["/root/.aptitude/config"]; } file { "/root/.aptitude/config": ensure => present, content => 'APT::Install-Recommends "0";'; }