4 ms·

Nice effort, the Arch User Repository is one of the benefits of the Arch way I feel. I have become so used to simply search "arch aur <VS Code>" or whatever I a

Nice effort, the Arch User Repository is one of the benefits of the Arch way I feel. I have become so used to simply search "arch aur <VS Code>" or whatever I am looking for, finding it there, git clone and install. I keep installing random userspace software and I do not think AUR let me down. On a side note, I keep thinking there are so many great ideas spread over the many Linux distributions and not having a single joint effort makes it hard from an adoption point. I love having choice but I would really like more users to be able to use a (any) distribution.

da_big_ghey 5y ago
If you are think search and git clone are nice, waiting until you find out of AUR helper! `paru -Syu visual-studio-code-bin`
- doubleunplussed 5y ago
  It's almost certainly a conscious choice to not use an AUR helper
  - brainless 5y ago
    I agree it is a conscious choice, I read it from the Arch Wiki, but to be honest I do not know why this can not be solved and accepted as a way forward.
christophilus 5y ago
I’ve only just started running Arch. One thing I don’t understand is the AUR security model. Aren’t you running arbitrary code / binaries built by some stranger on the interwebs on your machine? This is my biggest hesitation, and why I haven’t used AUR.
- spinax 5y ago
  Using the 80/20 rule, most AUR packages are simply the build script ("PKGBUILD") instructions and perhaps a patch if required, etc. (or say adding a missing .desktop file). The process involves your AUR tool (I use "pikaur") downloading them, then executing the build instructions _locally_ on your device. So your desktop is actually the one downloading the real source code and compiling it, then installing it. The 20% side of this is yes, there are some prebuilt binaries in AUR - usually because (a) they are vendor proprietary code with no source (Zoom, for example) or (b) so insane to build that the vendor does it and you use their binaries (Firefox for example - it's a monster to compile). Most of the time these packages are clearly labeled, usually with "-bin" in the name so you can easily avoid them. You are executing build instructions written by someone else, but the tools encourage you to actually review them (and pikaur for example can show them to you for review right then and there). There is a level of trust involved and yeah, bad actors do try and slip in ugly things but they're usually found pretty quickly because folks are actually reviewing-before-installing as encouraged. It's risk management on this one, you take some personal responsibility for using AUR to pay attention.
  - christophilus 5y ago
    Thanks! That makes a lot of sense. I’ll have to do a deep dive this weekend.
    - spinax 5y ago
      Quick bootstrap: you normally want a "helper" to handle downloading things and running the compile steps (it can all be done manually, and in fact you have to bootstrap yourself the first time that way). I prefer this one, pikaur, due to how well it integrates (looks and feels like pacman) and has a rich featureset: https://aur.archlinux.org/packages/pikaur https://aur.archlinux.org/packages/pikaur After getting that downloaded, compiled and installed then try a sample simple AUR package like "downgrade" - `pikaur -S downgrade` - to get feel for it. https://aur.archlinux.org/packages/downgrade/ https://aur.archlinux.org/packages/downgrade/ It really is kinda that simple, the rest is just learning the basic "how are Arch packages actually made?" which is a good thing to learn in general.
- Alexendoo 5y ago
  The idea is you read the PKGBUILD/install files so it's no longer arbitrary code, they're usually very short files. On updates you can review just a diff. AUR helpers present this to you so it's not a manual process Many packages are compiled from source rather than using prebuilt binaries, but when binaries are fetched it is something you'd see in the PKGBUILD itself. The binaries aren't included in the AUR itself, they'd usually be from the first-party of the software you're installing. For example google-chrome[1]'s package fetches the .deb from Google's server and unpacks it [1]: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=google-chrome https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=googl...

da_big_ghey 5y ago

If you are think search and git clone are nice, waiting until you find out of AUR helper! `paru -Syu visual-studio-code-bin`

doubleunplussed 5y ago
It's almost certainly a conscious choice to not use an AUR helper
- brainless 5y ago
  I agree it is a conscious choice, I read it from the Arch Wiki, but to be honest I do not know why this can not be solved and accepted as a way forward.

christophilus 5y ago

I’ve only just started running Arch. One thing I don’t understand is the AUR security model. Aren’t you running arbitrary code / binaries built by some stranger on the interwebs on your machine? This is my biggest hesitation, and why I haven’t used AUR.

spinax 5y ago
Using the 80/20 rule, most AUR packages are simply the build script ("PKGBUILD") instructions and perhaps a patch if required, etc. (or say adding a missing .desktop file). The process involves your AUR tool (I use "pikaur") downloading them, then executing the build instructions _locally_ on your device. So your desktop is actually the one downloading the real source code and compiling it, then installing it. The 20% side of this is yes, there are some prebuilt binaries in AUR - usually because (a) they are vendor proprietary code with no source (Zoom, for example) or (b) so insane to build that the vendor does it and you use their binaries (Firefox for example - it's a monster to compile). Most of the time these packages are clearly labeled, usually with "-bin" in the name so you can easily avoid them. You are executing build instructions written by someone else, but the tools encourage you to actually review them (and pikaur for example can show them to you for review right then and there). There is a level of trust involved and yeah, bad actors do try and slip in ugly things but they're usually found pretty quickly because folks are actually reviewing-before-installing as encouraged. It's risk management on this one, you take some personal responsibility for using AUR to pay attention.
- christophilus 5y ago
  Thanks! That makes a lot of sense. I’ll have to do a deep dive this weekend.
  - spinax 5y ago
    Quick bootstrap: you normally want a "helper" to handle downloading things and running the compile steps (it can all be done manually, and in fact you have to bootstrap yourself the first time that way). I prefer this one, pikaur, due to how well it integrates (looks and feels like pacman) and has a rich featureset: https://aur.archlinux.org/packages/pikaur https://aur.archlinux.org/packages/pikaur After getting that downloaded, compiled and installed then try a sample simple AUR package like "downgrade" - `pikaur -S downgrade` - to get feel for it. https://aur.archlinux.org/packages/downgrade/ https://aur.archlinux.org/packages/downgrade/ It really is kinda that simple, the rest is just learning the basic "how are Arch packages actually made?" which is a good thing to learn in general.
Alexendoo 5y ago
The idea is you read the PKGBUILD/install files so it's no longer arbitrary code, they're usually very short files. On updates you can review just a diff. AUR helpers present this to you so it's not a manual process Many packages are compiled from source rather than using prebuilt binaries, but when binaries are fetched it is something you'd see in the PKGBUILD itself. The binaries aren't included in the AUR itself, they'd usually be from the first-party of the software you're installing. For example google-chrome[1]'s package fetches the .deb from Google's server and unpacks it [1]: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=google-chrome https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=googl...