Merge fwupdate into fwupd

[hughsie]

I've opened this for initial comments. In Fedora the only user of libfwupdate is fwupd and the fwupdate command line tool. I think it makes sense to ship the fwupdate CLI unchanged as part of the fwupd project and to absorb the libfwupdate library interface into the uefi plugin in fwupd as an unexported static library. Benefits I can see include:

• fwupd and fwupdate are very similar names; a lot of OEMs are confused.
• fwupd already depends on efivar for other things.
• We're maintaining an artificial library interface when there is really only going to be one real user, and a debug tool.
• fwupd already has the CI and translation hooks in place for userspace software
• We don't need to check for features or versions in fwupd, we can just develop the feature (e.g. BGRT) all in one place.
• There's an impedance mismatch with the high-level GFile API fwupd uses and the low level API libfwupdate functions which provides lots of conversion fun.
• fwupd revs much quicker than fwupdate and also has quite a bit of community support.

I don't think it makes sense to absorb the efi part of fwupate, although if it makes sense to keep them in tree together I suppose that's fine with me.

@vathpela @aruiz @superm1 -- ideas? flames?

[superm1]

In general I like this idea, but it might be a little painful transition in distros to make it happen. I guess I would also like to ask what @vathpela's intention with it being separate in the first place was. Do you expect other user space applications to some day use this interface too?

fwupdate CLI unchanged as part of the fwupd project

If this was done, I'd like to see it land in /usr/lib/libexec similar to fwupdtool.

We don't need to check for features or versions in fwupd, we can just develop the feature (e.g. BGRT) all in one place.

+1

absorb the libfwupdate library interface into the uefi plugin in fwupd as an unexported static library

For quickly bringing it in - sure. I would expect over time to transition it to fully use glib. Also I would think that fwupdate cli isn't actually valuable when we have fwupdtool. Maybe need to add an unlock operation to raw devices in fwupdtool (that enables ESRT) but otherwise install-blob does "most" of the same thing that fwupdate CLI does.

fwupd already has the CI and translation hooks in place for userspace software

I think we do need some CI specifically for UEFI updates in fwupd still really. There have been non-obvious changes that have broken UEFI plugin. Maybe it would be easier to build a mock environment for ESRT and NVRAM variables with it in tree and moving to glib too.

I don't think it makes sense to absorb the efi part of fwupate, although if it makes sense to keep them in tree together I suppose that's fine with me.

This is part of where I think it would be a complicated transition for distros. The EFI application needs to get signed which means that package names that do the signing might have to adjust too. I think that all the package managers can handle it though.

Maybe the right answer is to bring the EFI part in tree too but for the distros generate packages that match the existing "efi" package name to make it an easier transition?

I think fwupd would be better equipped to manage the EFI application assets as well.

[superm1]

Closed with https://github.com/hughsie/fwupd/commit/b1e0ab98d1441f1e751ab7c30a32cacf6315ca85#diff-2f5c39c775e4cac7ebbeabed4cefca6a and many other commits.