[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: Correct transition path for moving EFI application



> -----Original Message-----
> From: Julian Andres Klode [mailto:julian.klode@gmail.com] On Behalf Of Julian
> Andres Klode
> Sent: Tuesday, July 3, 2018 11:35 AM
> To: Limonciello, Mario
> Cc: steve@einval.com; debian-efi@lists.debian.org
> Subject: Re: Correct transition path for moving EFI application
> 
> On Tue, Jul 03, 2018 at 03:39:58PM +0000, Mario.Limonciello@dell.com wrote:
> >
> >
> > Sent from VMware Boxer
> >
> > On Jul 3, 2018 09:58, Steve McIntyre <steve@einval.com> wrote:
> > >
> > > On Thu, Jun 28, 2018 at 02:25:10PM +0000, Mario.Limonciello@dell.com
> wrote:
> > > >Hi All,
> > >
> > > Hey Mario!
> > >
> > > >We’re right about to merge something in upstream fwupd that takes all of
> > > >fwupdate and puts it into the fwupd package.
> > > >
> > > >Fwupd will directly manage installation of the EFI application to the ESP
> > > >(including detection of the ESP location at runtime).
> > > >
> > > >In order to accomplish this I think it’s important that fwupdate is
> > > >no longer installed with fwupd.  I wanted to ask for some advice
> > > >however on what the proper packaging transition path is.
> > > >
> > > >Currently fwupdate has
> > > >
> > > >/usr/lib/fwupdate/fwupx64.efi
> > > >
> > > >This is installed to the ESP with a postinst script.
> > > >
> > > >Fwupd has:
> > > >
> > > >/usr/lib/fwupd/efi/fwupdx64.efi
> > > >
> > > >This is installed at runtime when a capsule update is installed.
> > > >
> > > >The file on the ESP is compared and if different the one in /usr/lib/fwupd/efi/
> > > >fwupx64.efi will be installed.
> > > >
> > > >So the files don’t strictly conflict, but I think it would be better
> > > >for fwupdate to be removed for transition purpose to avoid confusion
> > > >of which package is installed to the ESP (especially since fwupdate
> > > >is “currently” recommends for fwupd [that will be dropped]).
> > >
> > > Yes, fair enough. They don't conflict in terms of direct file paths in
> > > the packages, but they conflict in terms of functionality via the
> > > files in the ESP.
> > >
> > > >Reviewing
> > > >https://wiki.debian.org/PackageTransition
> > > >
> > > >It seems that this should be case #11, right?
> > > >Breaks: fwupdate (<< 11)
> > > >Replaces: fwupdate (<< 11)
> > > >Provides: fwupdate
> > > >
> > > >I tried to do this, but I encounter something along the lines of:
> > > >
> > > >dpkg: regarding fwupd*deb containing fwupd:
> > > >fwupd breaks fwupdate (<< 11)
> > > >  fwupdate (version 10-3) is present and installed
> > > >
> > > >dpkg: error processing archive fwupd*deb (--install):
> > > >  installing fwupd would break fwupdate, and
> > > >deconfiguration is not permitted (--auto-deconfigure might help)
> > > >
> > > >Errors were encountered when processing:
> > > >
> > > >fwupd*.deb
> > >
> > > The transition path looks perfectly OK to me, and it's exactly what
> > > I'd have suggested. How are you testing here? Using dpkg directly, or
> > > via apt?
> >
> > Thanks for confirming. I was doing it with dpkg. Do you expect apt would have
> resolved the upgrade path properly then?
> 
> Yes, apt would probably do one of the following:
> 
> 1. upgrades fwupdate to a version >= 11 (if one exists, idk, did not read it all)
> 2. passes --auto-deconfigure, which deconfigures fwupdate, and removes it later on
> 3. just removes fwupdate first
> 
> In any case, it would have the expected result.
> 
> --
> debian developer - deb.li/jak | jak-linux.org - free software dev
> ubuntu core developer                              i speak de, en

So after talking about this scenario upstream we decided that we will rename binaries
and EFI variables in fwupd to avoid conflicting with fwupdate.  That will allow both
to be installed side by side and be used independently.

fwupd will not need to install the binary to ESP at package installation, but rather we
have code that will support installation at runtime as necessary.

So it will be user choice if they want to keep fwupdate around and use it (for example
as a reference implementation for a system that doesn't have glib installed).

So as such I'm expecting that we'll actually be signing fwupd and fwupdate EFI binaries
both since they can be used independently.
I'm in the process of merging in the signing support from fwupdate into fwupd
and will upload to the archive later today.

Reply to: