4 ms·

AUR repository isn't supported by the core tools and packages. To use it one has to install external scripts. So it's by no means part of the system.

mar77i 8y ago
Urm, you need git, you need build tools... and pacman. That's it. But oh yeah, because I do these things by hand and check whether the source urls point to the place I'd actually like to install (and other code doesn't download external sources, eg. in the PKGBUILD or external scripts like *.install files), I'm suddenly an exception. I just noticed that the blue used on the Archlinux logo is actually quite consistent with Rick's hair color. https://i.imgur.com/kkE25w2.jpg https://i.imgur.com/kkE25w2.jpg Fits me. I don't give a damn.
- Foxboron 8y ago
  I'll assure you Rick has a blue-grayish color while the Arch logo is Navy Blue.
dozzie 8y ago
Which, as I said, very conveniently is glossed over by Arch users.
- JackCh 8y ago
  That's a problem with Arch users, not with Arch. It's unfortunately common that fanboys undermine the reputation of reasonable software.
  - dozzie 8y ago
    Oh yes, it is a problem with the users, not the software itself, but you don't get to separate the two in the case of an OS or distribution.
    - JackCh 8y ago
      > "but you don't get to separate the two in the case of an OS or distribution." Actually I do get to do that. It's an important distinction because if the software isn't at fault, then a technically competent user can safely use it by merely not being as dumb as the average user. But if the software itself is at fault, then the technically competent user should stay clear of it. Idiots will be idiots no matter the distribution. If it weren't arch, they might be downloading third party RPMs or debs from untrusted sources. Would that be reason for a technically competent person to avoid RHEL or Debian? Of course not.
      - dozzie 8y ago
        > It's an important distinction because if the software isn't at fault, [...] Though the software is at fault. It created a false sense of security, misleading the users. What else in Arch just feels secure, but in fact is not? And then, if the users around the software generally exhibit a jockey attitude, you get the whole environment built in a similar manner, not a robust one. The software may technically not be at fault and technically could be used in a safe manner, but you won't get much exposure to that, any such use will be cumbersome and difficult (because nobody uses it this way), so you still should stay clear of the software. So no, you don't get to separate the users and the OS/distribution.
        m45t3r 8y ago
        > Though the software is at fault. It created a false sense of security, misleading the users. What else in Arch just feels secure, but in fact is not? AUR never tried to pass false sense of security, it is explicitly declared as not supported everywhere. > And then, if the users around the software generally exhibit a jockey attitude, you get the whole environment built in a similar manner, not a robust one. The software may technically not be at fault and technically could be used in a safe manner, but you won't get much exposure to that, any such use will be cumbersome and difficult (because nobody uses it this way), so you still should stay clear of the software. So no, you don't get to separate the users and the OS/distribution. Except it is not, experienced users of Arch community vocally recommends new users to not blindly trust AUR, and the dangers of AUR is also documented everywhere. This is also one of the reasons that yaourt is shamed in public Arch communities like /r/archlinux, since it defaults to poor security behavior.
zanny 8y ago
All it takes to build air packages is makepkg from the core pacman package. With gut you can grab aur packages from the terminal, and hit is also core. Every Arch install must have pacman and hit is in base-devel, a package group in core all AUR pkgbuilds are designed to assume is installed.

mar77i 8y ago

Urm, you need git, you need build tools... and pacman. That's it. But oh yeah, because I do these things by hand and check whether the source urls point to the place I'd actually like to install (and other code doesn't download external sources, eg. in the PKGBUILD or external scripts like *.install files), I'm suddenly an exception. I just noticed that the blue used on the Archlinux logo is actually quite consistent with Rick's hair color. https://i.imgur.com/kkE25w2.jpg https://i.imgur.com/kkE25w2.jpg Fits me. I don't give a damn.

Foxboron 8y ago
I'll assure you Rick has a blue-grayish color while the Arch logo is Navy Blue.

dozzie 8y ago

Which, as I said, very conveniently is glossed over by Arch users.

JackCh 8y ago
That's a problem with Arch users, not with Arch. It's unfortunately common that fanboys undermine the reputation of reasonable software.
- dozzie 8y ago
  Oh yes, it is a problem with the users, not the software itself, but you don't get to separate the two in the case of an OS or distribution.
  - JackCh 8y ago
    > "but you don't get to separate the two in the case of an OS or distribution." Actually I do get to do that. It's an important distinction because if the software isn't at fault, then a technically competent user can safely use it by merely not being as dumb as the average user. But if the software itself is at fault, then the technically competent user should stay clear of it. Idiots will be idiots no matter the distribution. If it weren't arch, they might be downloading third party RPMs or debs from untrusted sources. Would that be reason for a technically competent person to avoid RHEL or Debian? Of course not.
    - dozzie 8y ago
      > It's an important distinction because if the software isn't at fault, [...] Though the software is at fault. It created a false sense of security, misleading the users. What else in Arch just feels secure, but in fact is not? And then, if the users around the software generally exhibit a jockey attitude, you get the whole environment built in a similar manner, not a robust one. The software may technically not be at fault and technically could be used in a safe manner, but you won't get much exposure to that, any such use will be cumbersome and difficult (because nobody uses it this way), so you still should stay clear of the software. So no, you don't get to separate the users and the OS/distribution.
      - m45t3r 8y ago
        > Though the software is at fault. It created a false sense of security, misleading the users. What else in Arch just feels secure, but in fact is not? AUR never tried to pass false sense of security, it is explicitly declared as not supported everywhere. > And then, if the users around the software generally exhibit a jockey attitude, you get the whole environment built in a similar manner, not a robust one. The software may technically not be at fault and technically could be used in a safe manner, but you won't get much exposure to that, any such use will be cumbersome and difficult (because nobody uses it this way), so you still should stay clear of the software. So no, you don't get to separate the users and the OS/distribution. Except it is not, experienced users of Arch community vocally recommends new users to not blindly trust AUR, and the dangers of AUR is also documented everywhere. This is also one of the reasons that yaourt is shamed in public Arch communities like /r/archlinux, since it defaults to poor security behavior.

zanny 8y ago

All it takes to build air packages is makepkg from the core pacman package. With gut you can grab aur packages from the terminal, and hit is also core. Every Arch install must have pacman and hit is in base-devel, a package group in core all AUR pkgbuilds are designed to assume is installed.