只有我一个人觉得 Arch 的 AUR 不好用吗?

需要编译并不是 aur 的限制，如果有人维护了 xxx-bin 的包，也可以直接安装二进制。

建议不要用 arch 了。

用了这么多年 aur 从来没碰到这个痛点
我唯一在 aur 里的 electron 程序是 vsode ，然而我直接用 bin 版不用编译

用 ubuntu 或者 debian 不就完了吗

听说 deb 包比较老，而且编译也有编译的好处，ABI 兼容更好

感觉用 archlinux 最大的优点就是软件包非常新，当需要比较新的软件时，Ubuntu 就只能源码编译了，而且最大的问题是，无法管理依赖，软件更新后也很麻烦，你是重新拉源码然后编译呢，还是不更新呢？

AUR 加上 AUR 助手就完美解决了这些问题，aur 助手能自动构建，追踪软件更新，管理依赖

至于编译很慢，这确实是问题，不过你要考虑到，AUR 的软件是社区自发维护的，如果一个软件编译需要很长时间，aur 可能提供 bin 包，（如果没有，你也可以上传）

不过我觉得 AUR 其实最大的问题是，里面的软件包都是打包者把官方提供的包修改成适合 archlinux 的包，也就是说，首先打包者完全不为软件负责，他们会说，请到上游反馈问题，然后反馈给上游，上游也是可以不负责的，因为 archlinux 不是 offical suported

作为很长一段时间的 Arch 用户兼几个 AUR 包的维护者，我认同 #5 的观点，尤其是后面 AUR 包的反馈问题。Arch Linux 吸引我的一直也不是 AUR ，尤其是 AUR 的包质量参差不齐，孤儿包比例不小。
不过在我看来 Arch 本来就不是一个适合大多数人的发行版，鱼与熊掌不可兼得，AUR 本来就不可能尽善尽美。

没觉得这是个问题，如楼上所言，AUR 仓库的安全性与可用性对我而言比这问题更大。

你完全可以自己写 pkgbuild 维护自己的打包，都用 Arch 了这点能力应该还是有的。

有时候依赖先滚上去，这个包的二进制还没更新，拉源码编译的 aur 包就有优势了

想要主流软件开箱即用的话，只能选红帽系或者 debian 系了，稍微小众点的发行版都不适合

1. AUR 是用来补全官方仓库里没有的包的，这些“软件包”通常只是一个 PKGBUILD 文件，这个文件是用来告诉系统的 makepkg 怎么打包的。总而言之，你用 AUR 是必然要先打包再安装的。

2. 至于打包过程是转换上游软件的 deb/rpm 包，还是下载源码自行编译，一般取决于这个 AUR 包的上传和维护者，甚至还有这个包的构建方式。（ AUR 有不少助手程序可以帮你实现自动化安装 AUR 包，换别的发行版装这种包，特别是需要编译安装的包，可能会更麻烦）

3. AUR 上面似乎有个约定俗成的惯例，包名有一个后缀 -bin 的包不需要编译。楼主不想编译安装的话，建议优先找这种包。

4. 楼主你的主题在该换行的地方没有换行，阅读起来很费劲。V2EX 发表主题的默认文本格式是 Markdown ，建议楼主复习一下 Markdown 的换行方式。

对于安全性我想说的是 PKGBUILD 指出了这个包所有的细节，要么是从源码编译，要么是从其它 RPM/DEB 包转换，这并非是 AUR 的问题。

aur 打包质量很差，经常编译一半失败，后面我都不用 aur 的包了。