It appears the enormity of replacing a directory with a file is just too much
for package managers in 2017.
I guess we might ship other things in /usr/libexec/fwupd/ in the future.
Automake and autoconf are impossible to fully understand and Meson now provides
everything we need for a much smaller, faster, and more understandable build.
See http://mesonbuild.com/ for more information.
I know Debian doesn't use libexecdir, but most other distros do. On Fedora it's
really strange to see a binary in /usr/libexec/fwupd/fwupd and supporting this
not-quite-servicedir is causing confusion in the Makefiles and also problems in
other external tools.
Simply redefine libexecdir if you need the daemon binary to be installed
somewhere different.
This is a large commit that removes all the providers and turns them into
plugins. I think having both providers _and_ plugins was super confusing.
Plugins are loaded at runtime so you could in theory develop a new plugin
without putting it in the fwupd source tree, although there are no installed
headers or PC files as I'm not sure it's a good idea at this stage.
This commit moves all the per-provider docs, tests, notes, debug dumps and test
data to plugin-specific directories -- these also allows the plugin author to
"own" more of the source tree so we don't enforce fu- prefixes and the style
guide everywhere.
This allows us to run the same action on all the plugins in the future, so we
could have a prepare(FuPlugin, FuDevice) and cleanup(FuPlugin, FuDevice) run
on *all* plugins, so doing an update using one plugin would allow us to work
around hardware quirks in other plugins.
If I've broken your out-of-tree provider it's trivial to port to the new API
with sed and a fixed up build file. If you need help please let me know.
Although it's convenient that you can just log in as root and add another
trusted key, it makes the selinux developers unhappy. Use a private keystore
in /var/lib/fwupd/gnupg to avoid the possibility of a somehow hacked fwupd
being able to export the root gpg secrets if any happened to exist.
If you've trusted keys other than the LVFS for metadata or firmware you'll need
to re-import them into this new location.
See b7f12bd377
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1303531
The DFU specification specifies that only one of the DFU interfaces has to
export a functional descriptor; I assumed they all had to. Adding support
for this kind of device rapidly turned into a massive restructure and it was
all too complicated anyway.
Reorganise the code so that we can support these kinds of devices and clean up
the API so it's sane and easy to use. This also allows us to generate the
GObject introspection GIR and to also install libdfu as a shared library.
If you've got any comments about the API, please shout now as when 6.0 is
released it will become API and ABI stable.
fwupdate will handle creating the appropriate BootNext entry.
No other changes are needed from fwupd.
Signed-off-by: Richard Hughes <richard@hughsie.com>
