Until now, rpi-base served rpi0/rpi1 + rpi2 + rpi3 all at once. The
variants were solely distiguished by the target architecture; it was
nice while it lasted, but now that rpi4 is on its way, we need to split
things up a little.
With the split,
* rpi-base depends on rpi-kernel, armv6l* only,
* rpi2-base depends on rpi2-kernel, armv7l* only
* rpi3-base depends on rpi3-kernel, aarch64* only,
To help migrate existing devices to the new base packages, rpi-base
will be an empty mega package for !armv6l* and depend on rpi2-base or
rpi3-base for the foreseeable future, thus resolving like this:
* rpi-base -> rpi2-base (armv7l*)
* rpi-base -> rpi3-base (aarch64*)
For now it's sufficient to have one package provide all subpackages, to
ease maintainance. The template can easiliy be split (as we did with
rpi-kernel) should the need arise some day.
rpi3-base actually existed back in 2017 (it depended on mainline kernel
instead of rpi-kernel) and became obsolete in 2018;
who would have known back then we may have to deal with rpi>3 some day...
Relates to: #29139
Acked-by: Duncaen <duncaen@voidlinux.org>
Until now, rpi-kernel served rpi0/rpi1 + rpi2 + rpi3 all at once. The
variants were solely distiguished by the target architecture; it was
nice while it lasted, but now that rpi4 is on its way, we need to split
things up a little.
With the split,
* rpi-kernel serves rpi0 + rpi1, armv6l* only
* rpi2-kernel serves rpi2, armv7l* only
* rpi3-kernel serves rpi3, aarch64* only
To help migrate existing devices to the new kernel packages, rpi-kernel
will be an empty mega package for !armv6l* and depend on rpi2-kernel or
rpi3-kernel (depending on target architecture) for the foreseeable
future, thus resolving like this:
* rpi-kernel -> rpi2-kernel (armv7l*)
* rpi-kernel -> rpi3-kernel (aarch64*)
Relates to: #29139
Acked-by: Duncaen <duncaen@voidlinux.org>
At least the CMDLINE expansion did break on the printf '%s' and we
got a newline for every parameter, which is wrong.
(I'm suprised nobody noticed this, and how I not noticed this myself)
- go isn't available in all archs and would have broken builds with
tests enabled, so disable tests in that case. someone with more
interest in the package can disable specific tests if they want
- use $depends instead of repeating the dependency list
