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?

That would work for any packages that require no compilation, for that task. For puppet labs releases, we build our debs in cows that provide clean build environments using pdebuild (using a similar rake task at https://github.com/puppetlabs/packaging/blob/master/tasks/deb.rake#L101). These cows are specific for a given release and architecture, so the same trick wouldn't work there. To provide arm releases for facter, we need to build on actual arm hardware.

FWIW I repackaged facter 1.7.5 as 'Architecture: all' and was able to install / run it on my arm-based systems. I had previously built a stubbed out dmidecode for this same bug on an earlier release of facter.

Appears to be collecting relevant info and not throwing any obvious errors.

Apparently dpkg isn't able to do architecture specific dependencies in arch:all packages. Building it arch-all is a dead end if dmidecode is to remain a Depends and not a Recommends. So the solutions could be:

1. Making dmidecode a Recommends and building arch all could be a good solution. dmidecode will be installed in most systems where it is available, and yet work on arm as well
2. Failing that it may make sense to build i386 and amd64 packages depending on dmidecode and an arch-all package for everything else. Maybe there's a way to make that work in the repo.
3. Failing that then building for all arch's is needed.

I think making dmidecode a Recommends is the best option

PR filed https://github.com/puppetlabs/facter/pull/763

PR #763 was resolved by updating the commit title and merging https://github.com/puppetlabs/facter/pull/768.

The fix has been merged to facter, so look for this to be released in facter 2.2.0.