[aur-general] package-base PKGBUILD with different architecture list for packages inside
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. 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) Thanks, Attila
On 05-10-2019 13:48, 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.
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)
Thanks, Attila
Not sure if it will work, but I suggest trying this : - remove arch=('x86_64' 'armv7h' 'aarch64') from the body - add the correct arch= inside all package_ functions In case that doesn't work, this might be a (rather crude) alternative : - keep arch=('x86_64' 'armv7h' 'aarch64') in body - in package_aspnet-runtime-2.1 remove arch=('x86_64' 'armv7h') add statements that create an empty package when $CARCH='aarch64' make normal package for 'x86_64' and 'armv7h' arches Lone_Wolf
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
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@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
participants (3)
-
Attila Greguss
-
Eli Schwartz
-
Lone_Wolf