Uploaded image for project: 'Community Package Repository'
  1. Community Package Repository
  2. CPR-5

Puppet is still uninstallable on ARM because facter depends on dmidecode

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Normal
    • Resolution: Done
    • Component/s: None
    • Labels:
      None
    • Template:

      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 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 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
          pedrocr 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
          pedrocr 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
          stahnma 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
          stahnma 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
          pedrocr 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
          pedrocr 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 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 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
          pedrocr 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
          pedrocr 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 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 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
          cbliard 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
          cbliard 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?
          Hide
          matthaus Matthaus Owens added a comment - - edited

          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.

          Show
          matthaus Matthaus Owens added a comment - - edited 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.
          Hide
          ethrbunny jon yeargers added a comment -

          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.

          Show
          ethrbunny jon yeargers added a comment - 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.
          Hide
          pedrocr Pedro Côrte-Real added a comment -

          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

          Show
          pedrocr Pedro Côrte-Real added a comment - 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
          Show
          stahnma Michael Stahnke added a comment - PR filed https://github.com/puppetlabs/facter/pull/763
          Hide
          michael.smith Michael Smith added a comment -

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

          Show
          michael.smith Michael Smith added a comment - PR #763 was resolved by updating the commit title and merging https://github.com/puppetlabs/facter/pull/768 .
          Hide
          matthaus Matthaus Owens added a comment -

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

          Show
          matthaus Matthaus Owens added a comment - The fix has been merged to facter, so look for this to be released in facter 2.2.0.

            People

            • Assignee:
              stahnma Michael Stahnke
              Reporter:
              pedrocr Pedro Côrte-Real
            • Votes:
              5 Vote for this issue
              Watchers:
              11 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: