efi: download wireless-regdb to ensure regulatory.db is in the snap
Makefile.vmlinuz uses apt to install dependencies, which recursively
resolves dependies when preparing chroot/. It installs
linux-modules-extra-$(KVER)-$(FLAVOUR) which depends on crda, which
depends on wireless-regdb, which installs /lib/firmware/regulatory.db.
Makefile.efi instead downloads and unpacks individual debs, ignoring
recursive dependencies. This resulted in wireless-regdb not getting
installed in the chroot, and thus UC20 efi based kernel snaps have no
wifi regulatory db.
efi: Ignore +N at the end of linux-image-uc20-efi-* package versions
The snap version is based off of the linux-uc20-efi version,
however the linux-image-uc20-efi-* packages come from the signed
source package which may have a +N on the version. Ignore the
+N for the version check.
vmlinuz: Update kernel version check for versioning changes
For pc-kernel the snap version is now based on the linux-uc20-efi
package version, so checking against SNAPCRAFT_PROJECT_VERSION
will fail. Instead, drive the expected kernel version from the
snap version and use that for the check instead.
Now that use of $(KVER) has been eliminated, only the
installation of the kernel image and initrd differ between the
install targets of the two makefiles. Move the common code to a
common install target, and make this depend on an install-image
target which is defined in the format-specific makefiles.
Rather than cluttering the makefile with conditionals, split it
up into two makefiles, one for the "efi" image type and one for
the "vmlinuz" type. Keep common definitions in the top-level
makefile, and include the appropriate format-specific makefile
based on the value of KERNEL_IMAGE_FORMAT.
Note that we are left with no generic way to determine the kernel
flavour, not that we really had a good, generic way to do it
before. Recipes are now epected to specify FLAVOUR in the
make-parameters section of snapcraft.yaml.
