Using ${pkgname}-${version}_${revision} can be ambiguous, since it can
be interpreted as the package's actual name. Using
${pkgname}>=${version}_${revision} is preferred.
Since we are here, make depends for pipewire itself also require
specific versions of the libspa-* packages.
The gufw-pkexec script hardcodes the path to the python module; this
made it error out:
python3: can't open file '/usr/share/gufw/gufw/gufw.py':
[Errno 2] No such file or directory
The issue was missed when the package was updated.
Using python entry points should be suggested to upstream, since that's
the standard way of distributing python programs with setuptools.
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>
