On Wed, Jul 17, 2024 at 05:51:21PM +0900, Masahiro Yamada wrote:
...
> > > > diff --git a/scripts/package/PKGBUILD b/scripts/package/PKGBUILD
> > > > new file mode 100644
> > > > index 000000000000..eb3957fad915
> > > > --- /dev/null
> > > > +++ b/scripts/package/PKGBUILD
> > > > @@ -0,0 +1,99 @@
> > > > +# SPDX-License-Identifier: GPL-2.0-only
> > > > +# Maintainer: Thomas Weißschuh <linux@xxxxxxxxxxxxxx>
> > > > +# Contributor: Jan Alexander Steffens (heftig) <heftig@xxxxxxxxxxxxx>
> > > > +
> > > > +pkgbase=linux-upstream
...
> Perhaps, this may make sense.
>
> Currently,
> pkgname=("${pkgbase}" "${pkgbase}-headers" "${pkgbase}-api-headers")
> is hard-coded.
>
> I do not think linux-upstream-headers make sense
> when CONFIG_MODULE is disabled.
>
> scripts/package/mkspec turns off with_devel
> when CONFIG_MODULE is disabled.
Yes, I think that is a reasonable change to make. In the face of that
potential change, would it make sense to slightly adjust the
makedepends? pahole is only needed when CONFIG_DEBUG_INFO_BTF is enabled
but I guess no other package building infrastructure makes dependencies
conditional in that manner.
Another thing I wonder about would be allowing the user to customize the
value of pkgbase, like
pkgbase=${PACMAN_PKGBASE:-linux-upstream}
because unlike Debian and Fedora, multiple versions of the same kernel
package cannot be installed at once. If I wanted to build a package
against mainline and -next and install them side by side, I could only
do so if they are named differently. This would allow one to provide
PACMAN_PKGBASE=linux-mainline and PACMAN_PKGBASE=linux-next to
accomplish that. Might be a hyper specific use case though, so I am not
opposed to disregarding it.
Cheers,
Nathan
