Pedro Côrte-Real That isn't exactly correct, as is noted in http://www.debian.org/doc/debian-policy/ch-relationships.html, conditional dependencies like those in facter result in separate packages with different dependencies. The i386 and amd64 facter packages correctly depend on dmidecode, and if we were to build arm specific facter packages they would not have that dependency.

The Packages file you link shows facter with all architectures from the 1.6 series, which is where I would expect to see them. The pull you link was merged and released in the Facter 1.7 series, and those packages are no longer architecture all, so they aren't advertised in the armhf Packages list, as is expected.

That's strange. I don't see why you couldn't build facter as arch-all with the dmidecode conditional Require evaluated at install time and not build time. Are you sure that Depends line only works at build time?

If that can't be done could you actually build facter on armhf? Right now facter is only being built for i386 and amd64?

We'd rather keep the requirement (and not a Recommends), because some people disable installing recommended packages, and it's actually not recommended. On i386/amd64 it is required. What we should do is a separate build for ARM. Currently the only ARM hardware we have to build upon is a raspberry pi. Does that produce armhf? It's been a while since I've played with those.

I wasn't arguing for a Recommends. I was saying that you could leave "dmidecode [i386, amd64, ia64]" on the Depends line of the arch all package. Assuming that apt can parse that at install time. If instead you want to do arch specific packages the raspberry seems to be armhf but you could just build it for the list of arches you already have up (armel, armhf, mips, mipsel, powerpc, sparc).

Those arch specific dependencies are handled at package build time, not package install time, which is why it can't be an all package and has to be an any package. If you look at the control file for one of the facter amd64 packages you'll see that the dependency isn't arch specific at that point. Here is the control file from facter 1.7.4 amd64:

Package: facter
Version: 1.7.4-1puppetlabs1
Architecture: amd64
Maintainer: Puppet Labs <info@puppetlabs.com>
Installed-Size: 319
Depends: ruby | ruby-interpreter, dmidecode, virt-what, pciutils
Section: ruby
Priority: optional
Homepage: http://www.puppetlabs.com
Description: Ruby module for collecting simple facts about a host operating system
 Some of the facts are preconfigured, such as the hostname and the operating
 system. Additional facts can be added through simple Ruby scripts.

Because facter was built on an amd64 machine for this build, the dmidecode dependency is left in the control file. We would need to build facter on an arm machine to get an arm build without the dmidecode dependency.

I know that currently the arch specific dependencies are being resolved at build time, but are you sure apt isn't able to resolve them at install time? If that's not possible just generating facter for all the arches you have should work but it does seem like a blindspot in apt if you can't have arch specific dependencies in arch all packages.

José Pedro Correia Arch specific dependencies are exactly why it can't be an arch all package, because the i386 and the arm packages are different (one depends on dmidecode, the other does not). The way to handle arch specific dependencies is to update the control file as we have and to build for each arch that we need to.

(taken from a comment on CPR-18 on 24/Feb/2014, which is a duplicate of this one)

I worked around this by creating a dummy dmidecode package with equivs, but it is a little too handcrafted. I too would prefer a more straightford way to install latest puppet on arm automatically.

I tried to look at the tasks/deb.rake code. With -a[arch] parameter, it is possible to build for multiple architectures in one go:

 def debuild args
   results_dir = args[:work_dir]
-  begin
-    sh "debuild --no-lintian -uc -us"
-  rescue
-    fail "Something went wrong. Hopefully the backscroll or #{results_dir}/#{Pkg::Config.project}_#{Pkg::Config.debversion}.build file has a clue."
+  # read target architectures from Pkg::Config?
+  ['i386', 'amd64', 'armel', 'armhf'].each do |arch|
+    begin
+      sh "debuild --no-lintian -uc -us -a#{arch}"
+    rescue
+      fail "Something went wrong. Hopefully the backscroll or #{results_dir}/#{Pkg::Config.project}_#{Pkg::Config.debversion}_#{arch}.build file has a clue."
+    end
   end
 end

(side note: it fixes the path to the log.build file too)
Then building with rake package:deb, all packages are created in pkg/deb directory

ls -1 pkg/deb
facter_1.7.5.670.dirty-1puppetlabs1_amd64.changes
facter_1.7.5.670.dirty-1puppetlabs1_amd64.deb
facter_1.7.5.670.dirty-1puppetlabs1_armel.changes
facter_1.7.5.670.dirty-1puppetlabs1_armel.deb
facter_1.7.5.670.dirty-1puppetlabs1_armhf.changes
facter_1.7.5.670.dirty-1puppetlabs1_armhf.deb
facter_1.7.5.670.dirty-1puppetlabs1.debian.tar.gz
facter_1.7.5.670.dirty-1puppetlabs1.dsc
facter_1.7.5.670.dirty-1puppetlabs1_i386.changes
facter_1.7.5.670.dirty-1puppetlabs1_i386.deb
facter_1.7.5.670.dirty.orig.tar.gz

Would it do the trick?