On 2024-07-08 09:53:42+0000, Nathan Chancellor wrote:
> On Mon, Jul 08, 2024 at 05:56:44PM +0200, Thomas Weißschuh wrote:
> > On 2024-07-07 22:50:46+0000, Nathan Chancellor wrote:
> > > On Sat, Jul 06, 2024 at 09:33:46AM +0200, Thomas Weißschuh wrote:
<snip>
> > > > diff --git a/scripts/package/PKGBUILD b/scripts/package/PKGBUILD
> > > > new file mode 100644
> > > > index 000000000000..fe899c77a976
> > > > --- /dev/null
> > > > +++ b/scripts/package/PKGBUILD
> > > > @@ -0,0 +1,83 @@
> > > > +# SPDX-License-Identifier: GPL-2.0-only
> > > > +# Maintainer: Thomas Weißschuh <linux@xxxxxxxxxxxxxx>
> > > > +# Contributor: Jan Alexander Steffens (heftig) <heftig@xxxxxxxxxxxxx>
> > > > +
> > > > +pkgbase=linux-upstream
> > > > +pkgname=("$pkgbase" "$pkgbase-headers" "$pkgbase-api-headers")
> > > > +pkgver="${KERNELRELEASE//-/_}"
> > > > +pkgrel="$KBUILD_REVISION"
> > > > +pkgdesc='Linux'
> > > > +url='https://www.kernel.org/'
> > > > +arch=(any)
> > >
> > > I see why you went this way but this feels a little dangerous because
> > > this means the package will be installable on architectures other than
> > > the one that it is built for. I think a better solution for this problem
> > > would be moving arch back to $UTS_MACHINE but setting CARCH to that same
> > > value in scripts/Makefile.package above. This diff works for me,
> > > allowing me to build an aarch64 package on x86_64:
> >
> > This is what I used in v1 of the patch.
>
> You had $UTS_MACHINE as arch but I don't see where CARCH was set for
> makepkg? If you tried to cross compile with v1, there was an error
> because the default CARCH value (the host) does not match the arch
> value, but explicitly passing CARCH to makepkg with $UTS_MACHINE should
> allow makepkg to build a package that is only installable on that
> machine?
Indeed.
> > But I felt that this only works by pure chance.
>
> I don't think it is by pure chance, it should be entirely based off of the
> builder's ARCH value, no? I might be misunderstanding something though.
"Chance" for the fact that UTS_MACHINE and Arch Linux CARCH are
matching.
> > IMO users of this feature should know what they are doing.
> >
> > That said, if anybody has strong opinions on this, I'll be happy to change it.
>
> I don't feel strongly about it but I think this is different from pretty
> much all of the other package builds, which only build a package that is
> installable/usable on one archictecture, and the solution seems
> simple/robust enough.
I'll pick up your proposal and will send v3 with it and your tags.
