In this mode, both the metadata and firmware is stored on the local filesystem
and distributed using a distribution system like OSTree.
Fixes https://github.com/hughsie/fwupd/issues/162
Now we have multiple remotes that can be enabled or changed at runtime we need
to do several things better:
* Only load components from remotes that are enabled
* Only load a component if a higher priority remote has not already added it
Rather than just appending all recieved metadata into one big XML file, save
the original metadata .xml.gz files in /var/lib/fwupd/remotes.d and only load
them in the correct priority order if the remote is known and enabled.
Remove the old /var/cache/app-info/xmls/fwupd.xml file, also noting it wasn't
really a cache file at all but actually something quite important.
This also moves the tests into one file as gnome-desktop-testing-runner
intentionally randomizes the order and runs them in parallel where allowed.
Since tests like get-updates have to be run after the metadata injection simply
put these into one test that calls a simple script.
Add the concept of 'remotes' that can dropped into /etc and used as firmware
metadata sources. This may be desirable when firmware is only accessable with
a valid support contract or from behind a VPN.
Make systemd and ConsoleKit support an optional compile time flag
with both enabled by default. If both are used, the ifdef/elif will
ensure only the systemd calls are used so there's no conflict.
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.
commit 99b317d4f7 introduced much
more strict confinement. This actually caused some regressions
though.
commit 3c54edb15e tried to fix
one of the problems, but didn't cover the rest.
The actual changes:
- Drop PrivateUsers=yes
This is causing crashes when initializing libsmbios
Presumably it's related to accessing memory.
- Add back in NoNewPrivileges
This hasn't caused any crashes for libsmbios for me.
- Remove ProtectKernelTunables
This is needed to access /sys for the dcdbas kernel
module used by libsmbios. Calls fail without it
- Add ReadWritePaths=/var/lib/fwupd /boot/efi
The refresh function was failing the first time due to
ProtectSystem=full being in effect and /var/lib/fwupd
being read only
Flashing UEFI capsules was failing due to being unable
to write to /boot/efi/EFI/$(EFIDIR)/fw/
For some reason NoNewPrivileges=yes causes the process to be killed when run on
hardware specifically from Dell. I can reliably reproduce this on my XPS 13 and
I assume it's something to do with libsmbios.
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.
