> > On Wed, Nov 04, 2020 at 06:30:54PM +0000, Limonciello, Mario wrote: > >> 在 2020-11-03星期二的 22:21 +0000，Limonciello, Mario写道： > >> > > -----Original Message----- > >> > > From: Boyuan Yang <by...@debian.org> > >> > > Sent: Tuesday, November 3, 2020 13:09 > >> > > To: sub...@bugs.debian.org > >> > > Subject: Bug#973715: fwupd-amd64-signed: Uninstallable; not binNMU- > >> > > friendly > >> > > > >> > > Package: fwupd-amd64-signed > >> > > Severity: grave > >> > > Version: 1.4.6+2 > >> > > X-Debbugs-CC: 93...@debian.org mario.limoncie...@dell.com > >> > > > >> > > Dear EFI Team, > >> > > > >> > > Package fwupd-amd64-signed currently cannot be installed on Debian > >> > > Unstable/Sid. It depends on fwupd (= 1.4.6-2) while Sid only has > >> > > fwupd > >> > > (= 1.4.6-2+b1). > >> > > >> > I'm sorry can you show me where this +b1 build is? > >> > > >> > I don't see it mentioned in https://tracker.debian.org/pkg/fwupd > >> > >> It is shown at https://buildd.debian.org/status/package.php?p=fwupd . > >> If you actually install a Debian Sid system, you can also find the > >> package with this version string. > >> > >> > >> > > It seems obvious that such dependency relationship made > >> > > fwupd/fwupd- > >> > > amd64-signed not binNMU-friendly. Please consider setting a version > >> > > range to allow binNMU-ed package to satisfy the dependency > >> > > relationship. > >> > >> Please consider reading https://wiki.debian.org/binNMU and see how can > >> things be improved. > >> > >> Thanks, > >> Boyuan Yang > > > >I think the problem here is that the EFI binary sign process just didn't > >run. @Steve McIntyre is that supposed to be automatic now? Or still manual? > > I saw earlier that it's just happened. It's still run manually. What > we've done for the other -signed packages to deal with the delay and > potentially inconsistent versioning is change the dependencies. > Instead of depending on *exactly* the same version as the signed > package (==), we switch to >= so that a delay in the new -signed > package being processed won't break installations. >
99.9% of the time that's probably sufficient. But the moment the structure of the NVRAM variable used by linux user space and EFI application changes this would break. So because of that it's safer to block installation.
