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

[Mario Limonciello]

Here is the revised preinst that should cover the different problems outlined:
https://salsa.debian.org/efi-team/fwupdate/commit/85533b1f392399ee53f88e71091044a69dabbdc4

It hasn't yet been uploaded to unstable, would like to align the correct
thing to do with breaks/conflicts first and do upload with both at same
time.

> There is also a bug in the packaging, which is that fwupdate has an
unversioned Breaks: against fwupdate-signed; if this is required, it
should be an unversioned Conflicts: instead. However, per the previous
comment, I think we probably need to do something else here (such as
making fwupdate-signed also be a dummy package built from fwupdate
source which depends on fwupd-signed, or dropping the Breaks: entirely
and ignoring the fact that fwupdate-signed is kept on disk, if that is
appropriate).

In Ubuntu fwupdate-signed has always been a real source package and real
binary package.  However in Debian fwupdate-signed has never existed, it
has always been fwupdate-signed-$ARCH.  So the Breaks that is there is
entirely for the purpose of Ubuntu transitioning.  In my opinion it
would be better to avoid having to introduce a fwupdate-signed binary
package in the fwupdate source package in Debian just for the purpose of
Ubuntu transitioning.

I think that keeping fwupdate-signed on the disk is not an appropriate
action, at least not without changes to fwupdate-signed.  It calls in a
postinstall script /usr/lib/fwupdate/install which is not longer
provided by the fwupdate package.

I think that leaves two options then:
1) Remove unversioned Breaks: fwupdate-signed from fwupdate source package,
   convert fwupdate-signed into transition package in Ubuntu as part of this SRU.
2) Change unversioned Breaks: fwupdate-signed from fwupdate source package into unversioned Conflicts: fwupdate-signed.
>From Steve's comment, I'm not sure this would work though.  So I think my preference would be <1> above.

Steve, can you validate that <1> should likely work?

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

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

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 fwupdate package in Ubuntu:
  Fix Released
Status in libxmlb package in Ubuntu:
  Fix Released
Status in fwupd source package in Bionic:
  Fix Committed
Status in fwupd-signed source package in Bionic:
  Fix Committed
Status in fwupdate 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

  A.
  1. install the new fwupd, and plugin the new docking - DW19.
  2. fwupdmgr get-devices and check if all internal device can properly show

  B.
  1. If you can get new cab file, try to use fwupdmgr install XX.cab to see if can work properly.

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

  D.
  1. Install an 18.04 Ubuntu Desktop system.
  2. Enable bionic-proposed.
  3. Run update-manager.
  4. Ensure that the fwupd and fwupd-signed packages are installed without error.
  5. Ensure that no files or directories from the old fwupdate package are left behind in /boot/efi/EFI/ubuntu, /var/lib/fwupdate, or /var/cache/fwupdate.

  * 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