You are not logged in.

#1 2022-04-26 18:22:12

anonworldusr
Member
Registered: 2015-12-19
Posts: 20

PKGBUILD best practices question

I have installed the AUR package solana-bin and everything works fine for the most part. However, there is a script (cargo-build-bpf) provided with this package that attempts to download and install an additional component (bpf-tools). This isn't necessarily an issue, however, it fails to complete the install process and throws an obscure "Permission Denied" error.

I did some analysis and found out exactly what was happening. The solana-bin PKGBUILD installs cargo-build-bpf and other included executables/scripts in /opt/solana-release/bin/. This poses an issue when cargo build-bpf attempts to create a symlink to the $HOME/.cache/solana/*/ installed bpf-tools in /opt/solana-release/bin/sdk/bpf since it's a root owned directory. This is what causes the "Permission Denied" error.

Now my question is how should this be handled?
Should the PKGBUILD be updated to automatically install bpf-tools in the manner that solana already tries to do it?
Should another AUR package be created to install bpf-tools?
Just looking for what a best practice solution should be, and I will make the appropriate fix.

I have already opened up an issue on the solana github project page, which was promptly closed since they "don't maintain, nor support any third party package manager installed bin". Fair enough.

Last edited by anonworldusr (2022-04-27 00:14:17)


2<x<1

Offline

#2 2022-04-27 12:11:44

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: PKGBUILD best practices question

Should the PKGBUILD be updated to automatically install bpf-tools in the manner that solana already tries to do it?

No, PKGBUILDs are not allowed to touch user folders at all .

https://archlinux.org/packages/community/x86_64/bpf/ has an excutable called bfptool , maybe solana can be convinced to use that ?


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#3 2022-04-27 15:20:37

anonworldusr
Member
Registered: 2015-12-19
Posts: 20

Re: PKGBUILD best practices question

Lone_Wolf wrote:

No, PKGBUILDs are not allowed to touch user folders at all .

Thanks for your reply. I am aware that PKGBUILDs aren't allowed to touch user folders. However, since symlinks to the $HOME dir are created in the /opt/solana-release/bin/sdk/bpf/dependencies folder it would be possible to just install them there to begin with maybe? It depends on where solana looks for them later I guess. It would still be possible to create a separate bpf-tools AUR repo and install it in a root dir and create the symlinks.

Lone_Wolf wrote:

https://archlinux.org/packages/community/x86_64/bpf/ has an excutable called bfptool , maybe solana can be convinced to use that ?

As for convincing solana to use bpftool, I don't think that's possible. Their bpf-tools is rolled in-house and is basically just a .zip of specific versions of llvm and rust. I don't even know if it's technically necessary to have it installed for solana to work properly if local versions are already installed, they force it with the installed cargo subcommand build-bpf though so maybe it's rust and/or llvm compiled w/ specific flags.

Last edited by anonworldusr (2022-04-27 15:23:28)


2<x<1

Offline

#4 2022-04-28 08:53:32

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: PKGBUILD best practices question

Looked a bit more at solana-bin PKGBUILD, realised it uses apache license and noticed there is  an aur package that builds from source.

https://aur.archlinux.org/packages/solana looks like it could be improved and made compliant with https://wiki.archlinux.org/title/Rust_p … guidelines .

The binary release used by solana-bin contains just a bunch of files without instructions and makes me wonder if it's suited for a a package or should just be extracted to /usr/local or some folder under users $home .

I woud focus on solana package or run the binary as user.

If you want to continue with solana-bin package, you do need to find some way to include their bpf-tools.
Does the solana  binary release download a binary of bpf-tools or build one ?

The former could be done in solana-bin, while for the latter a separate package seems a better choice.

Last edited by Lone_Wolf (2022-04-28 08:55:11)


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#5 2022-04-28 23:57:24

anonworldusr
Member
Registered: 2015-12-19
Posts: 20

Re: PKGBUILD best practices question

Lone_Wolf wrote:

Does the solana  binary release download a binary of bpf-tools or build one ?

The bpf-tools it downloads comes from https://github.com/solana-labs/bpf-tools/releases and contains executable binaries of rustc and llvm.
solana extracts these to a $HOME/.cache/... dir after install upon running the cargo subcommand build-bpf command for the first time.

Running with user privileges, it fails (due to the symlink it tries to create in a subdir of solana-bin install location).
What would be the best way to install bpf-tools outside of this userspace process?

If the $HOME/.cache/... install location doesn't really matter (I don't think it does, need to test), the PKGBUILD could install (extract) it into a subdir and create the symlinks to point there.

Lone_Wolf wrote:

The binary release used by solana-bin contains just a bunch of files without instructions and makes me wonder if it's suited for a a package or should just be extracted to /usr/local or some folder under users $home .

That would work, but would AUR no longer host the compiled binary then since it would be extracted to $HOME?

I wouldn't mind trying to clean up and use the source solana package, but having a quick bin is pretty nice.
Usually they are less of a headache to install than misconfigured source packages.


2<x<1

Offline

#6 2022-04-30 12:11:22

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: PKGBUILD best practices question

anonworldusr wrote:
Lone_Wolf wrote:

The binary release used by solana-bin contains just a bunch of files without instructions and makes me wonder if it's suited for a a package or should just be extracted to /usr/local or some folder under users $home .

That would work, but would AUR no longer host the compiled binary then since it would be extracted to $HOME?

It would indeed not be accepted in aur, but you could keep it  a local PKGBUILD only used on your system(s) .

anonworldusr wrote:

I wouldn't mind trying to clean up and use the source solana package, but having a quick bin is pretty nice.
Usually they are less of a headache to install than misconfigured source packages.

Unfortunately the binaries from upstream are usually intended for rpm or deb distros ( debian, ubuntu, fedora, suse, redhat to name a few) and often fail or have mysterious problems on archlinux.

A well-written & tested PKGBUILD building from source is worth the effort in my experience.
It also reduces maintenance in the long term and can (occasionally) even lead to improvements in upstream code.


back to bpf-tools / solana

adding the files needed for bpf-tools to solana-bin source array and let makepkg download them seems best option.

In package() The bpf-tools stuff could then be installed to /opt/solana-release/bin/sdk/bpf  .
This way the symlink should not be needed anymore.

(Ofcourse this requires runtime testing to verify if it works)


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#7 2022-04-30 23:11:16

anonworldusr
Member
Registered: 2015-12-19
Posts: 20

Re: PKGBUILD best practices question

Lone_Wolf wrote:
anonworldusr wrote:

I wouldn't mind trying to clean up and use the source solana package, but having a quick bin is pretty nice.
Usually they are less of a headache to install than misconfigured source packages.

Unfortunately the binaries from upstream are usually intended for rpm or deb distros ( debian, ubuntu, fedora, suse, redhat to name a few) and often fail or have mysterious problems on archlinux.

A well-written & tested PKGBUILD building from source is worth the effort in my experience.
It also reduces maintenance in the long term and can (occasionally) even lead to improvements in upstream code.

That makes sense, I'll keep this in mind and take a look at the solana source PKGBUILD to see if I'm able to make any improvements.

Lone_Wolf wrote:

adding the files needed for bpf-tools to solana-bin source array and let makepkg download them seems best option.

In package() The bpf-tools stuff could then be installed to /opt/solana-release/bin/sdk/bpf  .
This way the symlink should not be needed anymore.

Okay, great I'll give it a shot and test locally before submitting any changes to AUR.
Thanks for taking the time to look at this with me!


2<x<1

Offline

Board footer

Powered by FluxBB