On 2024-07-17 06:57:47+0000, Nathan Chancellor wrote:
> 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.
Ack.
> 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.
The pahole dependency optimization seems like an overcomplication.
Arch Linux in general is not hell-bent on minimizing dependencies,
for example there are no dev-packages at all.
Also if the kernel will require pahole in more cases it will create
churn.
> 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.
Ack.
FYI linux-upstream was picked to be consistent with pkg-debian and not
to conflict with the existing linux-mainline package in AUR [0].
[0] https://aur.archlinux.org/packages/linux-mainline
