[Bug 1820768] Re: [SRU] support new cab and new docking firmware upgrade in fwupd 1.2.5

[Mario Limonciello]

I'm unclear on the specifics goals required in terms of fwupdate compatibility during this transition.
1) 1 signed EFI binary in bionic?
2) Command line compatibility?
3) Other?

Steve, can you and/or Lukasz please clarify.

Currently in bionic:
1. fwupdate provides /usr/bin/fwupdate which is a command line debugging tool.
2. fwupdate provides an EFI application fwupx64.efi that gets installed into the ESP at deb install time
3. fwupdate-signed provides a signed version of <2>.
4. libfwup1 provides a library for applications to link with.  In the archive the only consumer of this is fwupd.

So which aspects are important to keep?
1. new fwupd provides /usr/lib/fwupd/fwupdate and /usr/lib/fwupd/fwupdtool which collectively support all the same functions as /usr/bin/fwupdate, but not identical syntax.  
As an example /usr/bin/fwupdate supported something like # fwupdate install -a GUID file.cap 
For fwupd this is /usr/lib/fwupd/fwupdtool install-blob file.cap GUID
2. new fwupd provides the EFI application fwupdx64.efi and it gets installed to ESP at first use.
3. new fwupd-signed provides signed version of <2>
4. libfwup1 library is not needed anymore.

---

Is the requirement strict command line compatibility?  Then to me I think the right answer is:
1) Rev fwupdate-signed as part of this SRU, make it a transition package.
2) In that transition package include a script in /usr/bin/fwupdate that either:
a) explains that this tool has been migrated and how to use the replacement tool
or
b) provides same syntax for a few common scenarios (such as install or debugging)
3) Make the fwupdate-signed package conflict/replace fwupdate package

This will accomplish not having two signed EFI binaries in the archive
anymore and let the command line tool still work from the previous path.

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1820768

Title:
  [SRU] support new cab and new docking firmware upgrade in fwupd 1.2.5

Status in OEM Priority Project:
  In Progress
Status in fwupd package in Ubuntu:
  Fix Released
Status in fwupd-signed package in Ubuntu:
  Fix Released
Status in libxmlb package in Ubuntu:
  Fix Released
Status in fwupd source package in Bionic:
  Incomplete
Status in fwupd-signed source package in Bionic:
  Fix Committed
Status in libxmlb source package in Bionic:
  Fix Committed

Bug description:
  * Impact

  Bios vendor is pushing to put the new design into cab file, and also
  new docking DW19 needs the new fwupd to support it.

  That needs new fwupd to support.

  * Background:
   1. most user does firmware update via gnome-software and it talk to fwupd.
   2. only very very limited user will call /usr/bin/fwupdate from the command line.
   3. the new fwupd will need a new fwupd-signed. So we will remove fwupdate-signed.

  * Current test result before we have something in proposed channel:
   1. new fwupd works well with gnome-software, so we should be safe to go.
   2. for those very limited user, they can call /usr/lib/fwupd/fwupdate to replace /usr/bin/fwupdate. so it should be safe to remove fwupdate.

  * Test case

  I
  1. install the new fwupd, and plugin the new docking - DW19.
  2. fwupdmgr get-devices and check if all internal device can properly show
  II.
  1. If you can get new cab file, try to use fwupdmgr install XX.cab to see if can work properly.
  III.
  1. If you can get a machine that have some firmware update pending, try to go gnome-software, and click refresh with the new fwupd, you should be able to see the pending firmware showed there. Which proves that it can properly be integrated with gnome. (ycheng-twn have a laptop with that condition, and he can verify that one)
  IV. As we need to remove fwupdate-signed and install fwupd-sign, we need to test if fwupdate(bionic) work well with fwupd-signed(the new verion in this SRU)

  * Regression potential

  Since the upstream maintainer is back up this upgrade, and he also
  works in a major computer vendor and works closely with the BIOS team,
  it should be fairly low risk.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1820768/+subscriptions