[Bug 1383332] Re: maas-cluster-controller is uninstallable on non-Intel architectures

[Colin Watson]

We found that syslinux-common has been reverted to Architecture: all in
unstable, so I'm going to cherry-pick that change.

** Package changed: maas (Ubuntu) => syslinux (Ubuntu)

** Changed in: syslinux (Ubuntu)
     Assignee: (unassigned) => Colin Watson (cjwatson)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to syslinux in Ubuntu.
https://bugs.launchpad.net/bugs/1383332

Title:
  maas-cluster-controller is uninstallable on non-Intel architectures

Status in “syslinux” package in Ubuntu:
  New

Bug description:
  [Impact]

  maas-cluster-controller cannot be installed on a non-Intel system at
  all. So, for example, a ppc64el cluster cannot be managed by a MAAS
  that is running on ppc64el.

  If we drop the dependency on syslinux-common for non-Intel
  architectures, then this would work around the uninstallability
  problem. But I think the consequence would be that MAAS running on a
  non-Intel architecture will no longer be able to boot any Intel nodes.
  This would be less bad, but still not good. Additionally, I don't
  think this would lead to any kind of sensible error message. The UI
  would appear to permit it, and it would fail.

  [Details]

  The following packages have unmet dependencies.
   maas-cluster-controller : Depends: syslinux-common but it is not installable

  The relevant dependency is:

  syslinux-dev | syslinux-common (<< 3:6.00~pre4+dfsg-5), syslinux-
  common

  Version: 1.7.0~beta1+bzr2781-0ubuntu1 in Utopic.

  maas-cluster-controller is "Architecture: all".

  syslinux-common is "Architecture: amd64 i386" since
  3:6.03~pre18+dfsg-1.

  This is a regression caused by a change to the syslinux package that
  landed in Utopic on 1 July.

  Since we're beyond final freeze now, fixing this in syslinux without
  risking regression is difficult. Any proposed solution that involves
  changing syslinux packaging needs to be approved by the release team
  first.

  15:17 <rbasak> To me, the multiarch solution seems the best, and maybe
  least regression risk for this point in the cycle I guess.

  15:18 <rbasak> Assuming that change would be acceptable to the release
  team.

  15:18 <cjwatson> I'm afraid not

  15:19 <cjwatson> It would be non-trivially complex, potentially affect
  a bunch of other stuff, and it would be a lot of work to make our
  checks understand multiarch.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/syslinux/+bug/1383332/+subscriptions