[aur-general] package-base PKGBUILD with different architecture list for packages inside

Attila Greguss floyd0122 at gmail.com
Sun Oct 6 12:47:07 UTC 2019


Thanks for the answer, in the end I split it out to a separate package.

I do not have a system with aarch64 so I could not test it, and someone
specifically asked for it. (in the end that person tested it for me)

If it can be built from source to aarch64 (what I don't know atm) it needs
to be a separate package anyway.

And I guess I'll have to set up a raspberry pi with aarch64 or something.

On Sun, 6 Oct 2019, 01:50 Eli Schwartz via aur-general, <
aur-general at archlinux.org> wrote:

> On 10/5/19 7:48 AM, Attila Greguss via aur-general wrote:
> > Hello,
> >
> > I have a PKGBUILD Here
> > <https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=dotnet-core-2.1>
> >
> > Is there a way to enable the commented out package in the PKGBUILD
> without
> > said package blocking the installation of the other packages on the
> > architecture it does not support?
> > I'm OK with splitting it out, but I thought I ask first if because I
> don't
> > know the capabilities of PKGBUILD/makepkg.
> >
> > Some (not necessary) context:
> > Package is for dotnet, and the source archive includes dotnet-host,
> > dotnet-runtime, aspnet-runtime, dotnet-sdk for x86_64 and armv7h. For
> > aarch64 it does NOT contain aspnet-runtime files, but all the rest.
>
> Yes, and it is also repackaging someone else's prebuilt binaries instead
> of building from source (and the source code is available). Is there a
> reason the package name does not include the word "bin" in it?
>
> Also generally why not just build from source, exactly like the
> unversioned package in [community]?
>
> > I tried to specify the architecture list for aspnet-runtime in the
> > PKGBUILD, but if someone tries to install any of the other packages on
> > aarch64 it will fail. (see commented out part in file)
>
> Well, no it won't fail. What will fail is trying to build it in the
> first place, since adding a split package whose list of arches is
> smaller than the global arch=() list is a broken concept. The first
> thing makepkg will do is check if all packages contain valid metadata,
> and on aarch64 it will refuse to even try to build anything at all,
> because it can tell it won't work.
>
> Building from source would fix this, since I assume the source code
> supports aarch64?
>
> ...
>
> I would like to know how this was ever a problem. Did you not try to
> build the package for aarch64 before uploading it?
>
> --
> Eli Schwartz
> Bug Wrangler and Trusted User
>
>


More information about the aur-general mailing list