Resolves installation for local CAB files that have `VersionFormat`
set but not yet also set from metadata.
In the first pass ignore the version format. This will rule out all
other checks such as GUID and protocol.
Then apply version format to the device if specified in the CAB.
Lastly do a second pass with all requirements set.
In 1de7cc we checked the version format when checking for update, but there are
many other places that are doing verfmt-insensitive comparisons. For instance,
the predicates in <requires> all fail if the device version format is plain.
his breaks updating some NVMe drives where the `ne` requirements are not
semantic versions.
To avoid trying to catch all the bugs in different places, and in case we have
a future verfmt that should be treated another way, refactor this out in to a
common function and deprecate the old function.
These are devices that we have to be careful with the version numbers, for
instance only updating from versions that have already had data migration
completed.
The new flag can be set in quirk files or on the objects directly.
Currently devices with a matching GUID will match any metadata that
has the same GUID.
For Dell in the future there will be a situation that the same GUID
is supported by two different FwupdDevice objects but the payload
required for the different objects will vary.
So start matching the protocol and the GUID both to make sure that
the right Fwupd device gets matched from the metadata.
We painted ourselves into a corner when we added the `LVFS::VersionFormat`
metadata key, as using newer keys like `bcd` would not be recognised by older
versions of the daemon as there was no explicit fallback path.
This allows plugins or devices to 'upgrade' from simpler formats like:
* `pair` -> `bcd`
* `quad` -> `intel-me`
* `triplet` -> `surface`
* `plain` -> `misc-defined-vendor-format`
This means the LVFS can write multiple `LVFS::VersionFormat` keys, although the
'older' version format has to be listed first to preserve compatibility with
older daemon versions that just validate the first matching node.
This leads to madness, as some formats are supersets of the detected types,
e.g. 'intel-me' is detected as 'quad' and 'bcd' is detected as 'pair'.
Where the version format is defined in a specification or hardcoded in the
source use a hardcoded enum value, otherwise use a quirk override.
Additionally, warn if the version does not match the defined version format
If the user is trying to install version '20190104' on something with the
existing version '1.2.3' then something has gone wrong. Ensure the device
release version format matches the release version format and fail to apply the
update if this is not true.
In the common case setting the version with fu_device_set_version('1.2.3')
would set the version format to TRIPLET, and setting <release version='1.2.3'>
so no action is required. In cases where the version format could be ambiguous
then the format should be set both in a quirk and also in the metainfo file.
In the future we'll want to use this flag to signify if the release is an
upgrade, downgrade, below the version-lowest, or if it is locked in some way.
The libxmlb library is much faster to query, and does not require the daemon
to parse the XML metadata at startup. It's a zero-copy mmap design that is more
modern and less clunky.
RSS has reduced from 3Mb (peak 3.61Mb) to 1Mb (peak 1.07Mb) and the startup
time has gone from 280ms to 250ms.
Currently if you download a CAB file from LVFS and try to install it
on a daemon compiled without GPG it will fail to install since LVFS has signed
it. You had to make an intentional decision to disable GPG.
Allow this scenario to work just as if the CAB file were unsigned, but save
a warning in the logs that it happened.
When using failed to open firmware.cab we pass in a device ID of '*' which
tells the daemon to update anything that matches. The current implementation
will fail in two ways:
* If duplicate hardware is installed (for instance two Unifying receivers) then
only the first matching device will be updated.
* If the firmware archive contains two different images then we only try and
upgrade the first device that matches. This means we're unable to update
composite devices using one firmware file.
To fix both issues, carefully build a list of tasks that can be processed using
the given firmware and installed devices, request authentication using all the
different action IDs, then upgrade all the devices one-at-a-time.
Based on a patch by Mario Limonciello <mario.limonciello@dell.com>, many thanks.
