Community Package Repository
  1. Community Package Repository
  2. CPR-5

Puppet is still uninstallable on ARM because facter depends on dmidecode

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Normal Normal
    • Resolution: Unresolved
    • Labels:
      None

      Description

      As can be seen in:

      http://apt.puppetlabs.com/dists/wheezy/main/binary-armhf/Packages

      facter is again depending on dmidecode on all architectures, instead of just x86 and ia64 where it actually makes sense. This is actually the same issue reocurring:

      https://projects.puppetlabs.com/issues/19678

      This makes puppet uninstallable on a raspberrypi. The solution is to do the dmidecode requirement conditional on architecture. This pull request was used to fix this but apparently only on facter 1.7, which isn't out yet?

      https://github.com/puppetlabs/facter/pull/416

        Issue Links

          Activity

          Hide
          Matthaus Owens added a comment -

          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.

          Show
          Matthaus Owens added a comment - 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.
          Hide
          Pedro Côrte-Real added a comment -

          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?

          Show
          Pedro Côrte-Real added a comment - 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?
          Hide
          Michael Stahnke added a comment -

          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.

          Show
          Michael Stahnke added a comment - 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.
          Hide
          Pedro Côrte-Real added a comment -

          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).

          Show
          Pedro Côrte-Real added a comment - 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).
          Hide
          Matthaus Owens added a comment -

          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.

          Show
          Matthaus Owens added a comment - 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.
          Hide
          Pedro Côrte-Real added a comment -

          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.

          Show
          Pedro Côrte-Real added a comment - 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.
          Hide
          Matthaus Owens added a comment -

          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.

          Show
          Matthaus Owens added a comment - 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.
          Hide
          Christophe Bliard added a comment -

          (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?

          Show
          Christophe Bliard added a comment - (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?

            People

            • Assignee:
              Michael Stahnke
              Reporter:
              Pedro Côrte-Real
            • Votes:
              3 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated: