为 macOS 提供包管理器的项目有：Homebrew、MacPorts、Fink、Gentoo Prefix、nix、pkgsrc。 这些包管理器的发展如何？对 Apple Silicon 的支持度如何？
难道不是 homebrew 一家独大嘛 
7 个赞
看样子是这样的（悲） 
不过 brew 不需要 sudo 让我很不放心，所以在换到 Apple Silicon 之前考虑要不要以后换一个别的。
我从 homebrew 换到 macports 有一年多了，目前还没出现什么过什么问题。感觉比 homebrew 好用。
Nix 也用过，只安装 Command-line 还好，GUI应用还要和 homebrew一起用，不知道目前这个问题解决了没？
1 个赞
pkgsrc 支持 Apple silicon，虽然不是从最新的 macOS 编译的但是不影响使用（当然我也不推荐装最新的 macOS）
1 个赞
啊？难道不是用了 sudo 才让人不放心吗 
这我又要好好说道说道，Homebrew 对自己的 formula 安全性不够信任，骗用户说不用 sudo 才比较先进的事了。
至少 pkgsrc 是有 VPS 公司在赞助，连所有包同时都装上的测试都做的。
1 个赞
Macports 和 Nix 到现在还是都要创建一堆奇怪的用户吧？
一直用Homebrew，感觉挺好的啊，不放心的就点进去看它的安装脚本，一般都非常简单。一般常用的app产生的垃圾也都管清理。
1 个赞
没辙，换的新电脑肯定会装新版 macOS，而且不更新到最新系统我比较容易担心会被黑客攻击（因为系统更新肯定会带安全性更新）。 
brew 不需要 sudo，应该是通过魔改了某些文件夹的读写权限来做到的吧？
到目前为止 Mojave 都还是能收到安全更新的
说不上魔改，也就做了一步 sudo chown，现在也不是默认装到 /usr/local 了，至少比以前好一点。
是不是说反了呀？有sudo才不放心，极度不放心
4 个赞
homebrew在/usr/local/Cellar目录下吧。
大家一般用包管理器装了什么命令啊？我是用brew来安装autoconf、bat、cmake、dos2unix、fd、fzf、htop、ipcalc、iperf3、irssi、less、ncdu、node、p7zip、pyenv、pypy3.10、ripgrep、rsync、sdcv、smartmontools、telnet、texinfo、the_silver_searcher、watch、wget和一些编译emacs用的开发库。
这和 homebrew 没直接关系，主要是用户（我）不信任他们而已。或者说，重点在于“应不应该”，“需不需要”，无脑 sudo 就是“懒政”，应该抵制。
就像苹果的软件，也有一定的检查（审核），安装也是按需 sudo，大多数也不需要 sudo 。
我认为日常用的软件必须从可信来源下载。一般的 macOS Application 不需要 sudo 也能安装，但是 GUI 下 macOS 是会验证有从可信来源的簽名才会放行的，如果软件被篡改，系统是能发现并阻止的，哪怕不是可信来源的软件，也有沙盒机制保㡳。在终端运行的程序，为了方便是很多人是关掉这个验证的，不然多次从 shell 运行同一个程序性能会严重降低，而且没有沙盒保护，所谓 GUI App 不需要 sudo 所以终端下用包管理器也不用 sudo 的理由站不住腳。pkgsrc 从下载 distrubution 时有 GPG key，软件也是测试后才放到仓库，安装单个包时也会 verifiy signature，用 sudo 安装包保证除非恶意软件有管理员权限，不然不会被篡改。而 brew 对在 path 变量里天天运行的程序不做任何权限上的保护，本身做为知名软件也没有做对自身完整性验证，有把常用命令替換成恶意软件的风险极大，我是很不放心的，相信题主也是有同样的担心
man pkg_add 的加粗段落，提醒用户小心木马，brew 就沒有这样的说明，安全意识不是一个级別的
brew 只提供软件的 SHA 而不是 GPG 签名，不能对软件的来源做保障，在 formula 没有权限保护时就更槽了。
Since the pkg_add command may execute scripts or programs contained within a package file, your system may be susceptible to “Trojan horses” or other subtle attacks from miscreants who create dangerous package files.
You are advised to verify the competence and identity of those who provide installable package files. For extra protection, use the digital signatures provided where possible (see the pkg_install.conf(5)), or, failing that, use tar(1) to extract the package file, and inspect its contents and scripts to ensure it poses no danger to your system’s integrity. Pay particular attention to any +INSTALL or +DEINSTALL files, and inspect the +CONTENTS file for @cwd, @mode (check for setuid), @dirrm, @exec, and @unexec directives, and/or use the pkg_info(1) command to examine the package file.
4 个赞
那还好，看来以后可以尝试在新的大版本的末期（下一个新版本快出来的时候）升级，或者隔年升级大版本了。
我以前也用 mac，后来因为 nix 在 mac 上支持比较糟糕就完全抛弃 mac 全部转移 linux 上了。
GUI 应用在 mac 上的特殊性，有两部分，一个是 lanuch pad/spotlight 的索引，一个是构建出 app 那个包。
前者如果不通过脚本来做软链或是加查找路径（我记得 brew 好像有些行为是和这个有关）才可以，这个不属性 nix 本身的功能，nix 本意就是仅在 nix 自己维护的极个别目录下完成整个体系的构建，可能 nix-darwin 一类的可以做类似的行为，就像 nixos 是把 desktop 文件链进一个固定的 tmpfs 目录下，然后通过 wrapper、patch、xdg data dir 来让 DE 找到对应的信息。
后者那个得看维护人了，nixpkgs 上 darwin 的维护人很少的，上游构建资源也很吃紧。有些去处理动态链接库的会有人维护，但专门再去增加一个 app 构建的，可能不少包都没人管的，你想要只能自己来 pr。
真要在 mac 上 nix，就不要当成像 brew 那样的系统包管理来用。只当成项目本身的开发/生成环境工具会比较好。
1 个赞
arm64 上应该改了，是 /opt/homebrew/Cellar
nix 创用户是设计特性，为了在构建的时候用特定的干净用户和组，这也是沙盒的一部分。在多用户模型式，为了让同系统上不同用户可以在相同的环境下构建，所以有这么个东西。 单用户模式下就没有了，因为在这个机器上就这个用户会用 nix，那么就没有必要建这个。
当然这个行为对 reproducible 有没有实际用处，我觉得是没有，但它是这么设计。