| Git Clone URL: | https://aur.archlinux.org/vlang-bin.git (read-only, click to copy) |
|---|---|
| Package Base: | vlang-bin |
| Description: | Simple, fast, safe, compiled language for developing maintainable software (binary release) |
| Upstream URL: | https://vlang.io |
| Keywords: | language programming v vlang |
| Licenses: | MIT |
| Conflicts: | v, vlang, vlang-git |
| Provides: | vlang |
| Submitter: | ragouel |
| Maintainer: | Chewing_Bever |
| Last Packager: | Chewing_Bever |
| Votes: | 4 |
| Popularity: | 0.037085 |
| First Submitted: | 2020-03-17 22:41 (UTC) |
| Last Updated: | 2024-03-21 10:02 (UTC) |
The only way I was able to make it run, was to grant 777 recursively on /usr/lib/vlang/cmd, which is a potential security risk. Use at your own risk.
We should be able to solve the chmod 777 problem once upstream cuts a new release. See this commit.
@chovy: you seem to be misunderstanding the point of v up and what a package manager is and does. I encourage you to read up on those, and you'll understand why you must never run v up (unless you want to break your system) :)
Edit (to be clearer): v up does have a reason to exist, as it is useful in two cases: when you don't have a package manager (eg. on Windows), or if you don't want to (or can't) install v system-wide (eg. you are on the someone else's machine and you don't have permission to install packages, so you just install v in your user's home folder).
sudo v up still updated it. I guess that is newer than what yay -S vlang-bin installs.
@chovy It requires sudo because this package installs v in a system directory which requires superuser permissions to write to. This shouldn't be a problem if you're using this package though since you should upgrade via pacman, not v up.
How come v up requires sudo v up to work? The vlang guys say this shouldn't be required.
Adding to my out-of-date message, sed s/0.1.29/0.2/ -i PKGBUILD && updpkgsums && mksrcinfo is enough to update the package :)
@lberrymage Touch away...
Oh wait... this is the -bin package. The other workaround is to touch each binary in the cmd/tools directory so their mtime is later than that of their respective source code.
@lberrymage I modified the patch offsets but 777 permissions are still needed.
Pinned Comments
lberrymage commented on 2021-01-20 05:09 (UTC) (edited on 2021-01-20 05:09 (UTC) by lberrymage)
We should be able to solve the
chmod 777problem once upstream cuts a new release. See this commit.ragouel commented on 2020-06-13 02:07 (UTC)
The only way I was able to make it run, was to grant 777 recursively on
/usr/lib/vlang/cmd, which is a potential security risk. Use at your own risk.