mise bootstrap packages upgrade批量升级主机系统包的命令行指南【免费下载链接】misedev tools, env vars, task runner项目地址: https://gitcode.com/GitHub_Trending/mi/misemise bootstrap packages upgrade是 mise 中用于升级[bootstrap.packages]已声明且已安装系统包的命令它刷新各包管理器的元数据并让 apk、apt、aur、dnf、pacman、brew、brew-cask、flatpak、flatpak-user、mas、winget 等十余种管理器各自升级到最新可用版本。读完本文你将掌握该命令的完整参数、各管理器差异化升级语义、底层执行流程以及如何与apply、use、prune等兄弟命令配合维护主机软件状态。命令总览该命令的官方 CLI 参考文档位于 docs/cli/bootstrap/packages/upgrade.md属于mise bootstrap packages子命令家族完整家族见 docs/cli/bootstrap/packages.md。用法mise bootstrap packages upgrade [FLAGS] [PACKAGE]…别名up效果modifies state修改系统状态源码位置src/cli/system/upgrade.rs命令核心职责一句话概括刷新包管理器元数据并升级配置中那些已经安装的包。未安装的包会被跳过——那是mise bootstrap packages apply的工作。包也可以显式以manager:package形式传入无需预先写入配置。升级 vs 安装与 apply 的分工在 mise 的主机包体系中apply与upgrade是两个互补的收敛动作动作命令目标对象典型场景安装缺失包mise bootstrap packages apply配置了但尚未安装的包新机器、新容器、新增声明升级已装包mise bootstrap packages upgrade配置了且已安装的包例行维护、安全更新声明并安装mise bootstrap packages use写入配置并安装缺失部分添加新包两者共享同一个底层执行驱动见下文“源码剖析”区别只在于对“已安装”状态的处理方向apply跳过已安装的包latest接受任意已装版本不会每次触发升级upgrade则跳过未安装的包并在发现缺失时给出提示mise bootstrap packages upgrade # 若存在未安装的包mise 会警告并提示 # N package(s) not installed — run mise bootstrap packages apply first[bootstrap.packages]声明格式与语义详见 docs/bootstrap/packages/index.md。每个条目以manager:package version为键值latest表示接受管理器安装的任意版本值也可以是在管理器原生格式下的版本固定pin例如apt:curl 8.5.0-2ubuntu10。各包管理器的升级行为upgrade对每种管理器采用其原生升级路径mise 只负责编排与状态核对管理器升级动作是否尊重配置中的版本固定pinapkapk upgrade --available --update-cache仅针对已安装的配置包是aptapt-get update后执行apt-get install --only-upgrade仅已安装的包成为升级目标是aur仅重建配置的 AUR 包不升级机器上所有 foreign 包否pin 仅状态可见dnfdnf upgrade -y --refresh仅触碰已安装的包是pacmanpacman -Sy后仅升级配置的包否pin 被跳过并警告brew重新解析 formulae.brew.sh APIpour 当前 bottle 替换旧 keg重指链接否brew-cask安装当前 cask artifact否flatpak/flatpak-user分别在--system/--user作用域内更新配置的应用与运行时否mas对已安装应用执行mas upgrade id否winget对每个已安装的配置包执行精确 ID 的winget upgrade否plugin由插件声明的PackageUpgrade相关钩子决定需插件实现取决于插件下面按管理器逐一展开细节可对照各管理器文档页面。apkAlpine Linux文档见 docs/bootstrap/packages/apk.md。upgrade运行apk upgrade --available --update-cache仅针对已安装的配置包。状态检查使用只读的apk info -e -v。配置中的 pin 以 apk 原生nameversion语法传递因此apk:zlib-dev 1.3.1-r2这类固定版本会在升级时被尊重。aptDebian / Ubuntu文档见 docs/bootstrap/packages/apt.md。upgrade先运行apt-get update再对配置包执行apt-get install --only-upgrade——--only-upgrade确保未安装的包不会意外变成安装目标但 apt 仍会解析这些升级所需的依赖。状态检查使用dpkg-query只读绝不提权。pin 以nameversion原生语法传给 apt。aurArch 用户仓库文档见 docs/bootstrap/packages/aur.md。upgrade只重建配置的 AUR 包不升级机器上所有 foreign 包助手在构建时仍可解析依赖。由于 AUR 助手构建的是当前 PKGBUILD 而非历史版本版本 pin 只是状态展示性质请为可自动安装的条目使用latest。dry-run 只显示助手调用不会替你抓取并审查 PKGBUILD。dnfFedora / RHEL 系文档见 docs/bootstrap/packages/dnf.md。upgrade运行dnf upgrade -y --refresh只触碰已安装的配置包并强制刷新元数据。pin 以name-version或name-version-release原生语法传递。注意仅支持 dnf不支持仅 yum 的旧系统。pacmanArch / Manjaro文档见 docs/bootstrap/packages/pacman.md。upgrade先运行pacman -Sy再仅升级配置的包通过Provides满足的请求会被跳过以避免替换已安装的 provider。Arch 仓库只保留每个包的最新版本因此 pacman 条目无法按固定版本安装——apply会跳过带 pin 的条目并警告status则仍报告version mismatch。文档同时强调Arch 官方只支持全系统升级pacman -Syu单独升级个别包属于 partial upgrade滚动发行工作站上应优先自行执行pacman -Syu。brewHomebrew formula无需安装 Homebrew文档见 docs/bootstrap/packages/brew.md 的 Upgrades 一节。upgrade重新解析配置的 formula 与 formulae.brew.sh APIpour 任何当前版本与已链接 keg 不同的 formula——新 keg 替换旧 keg链接重指与brew upgrade的流程一致。由于 bottle 只存在于 formula 的当前版本“升级”与“安装当前 bottle”本质上是同一操作。mise 不 shell 到brew而是直接抓取 API 元数据、校验 sha256、下载 ghcr.io 的 bottle并执行与 brew 相同的 relocation、code-signing 与 linking 工作。brew-caskcask 应用同样见 docs/bootstrap/packages/brew.md。upgrade安装当前 cask artifact 并替换旧版本。对声明auto_updates: true的自更新应用mise 遵循 Homebrew 的默认决策latest与匹配的 receipt 版本会跳过。其余 cask 只有在单一 owned app 的实时CFBundleShortVersionString/CFBundleVersion指示更旧版本按 Homebrew 比较规则时才替换当前、更新、不可读或不可比较的版本一律跳过替换。dry-run 报告决策但不替换应用。替换/Applications下的 app 属于与brew reinstall --cask同类操作macOS 可能因此撤销该应用的隐私与安全TCC授权升级后需在系统设置中重新授权。flatpak / flatpak-userLinux 桌面应用与运行时文档见 docs/bootstrap/packages/flatpak.md。flatpak对应系统级安装传--systemflatpak-user对应用户级安装传--user。upgrade在各自作用域内对配置的应用与运行时执行flatpak update。mise 始终显式传递作用域因此 status / apply / upgrade 操作同一套安装。Flatpak 无法通过这些命令安装任意历史版本不支持 pin配置请使用latest。masMac App Store 应用文档见 docs/bootstrap/packages/mas.md。upgrade对已安装应用执行mas upgrade id。包名必须是数字 ADAM ID如497799835对应 Xcodebundle identifier 不合法。App Store 操作可能需要已登录 Apple Account、macOS 认证、已购买/认领付费应用等mise 只透传mas的报错不代购应用。wingetWindows 包文档见 docs/bootstrap/packages/winget.md。upgrade对每个已安装的配置包执行精确 ID 的winget upgrade以--id--exact传递绝不接受模糊匹配且总是先刷新 WinGet sources。升级以静默模式运行接受 WinGet 暴露的包与源协议安装器仍可能通过 UAC 要求 Windows 提权mise 不会绕过 UAC。声明式移除、import、prune 暂不属于 WinGet 集成的初始范围。参数与标志详解[PACKAGE]…参数以manager:package形式显式指定要升级的包例如brew:postgresql17、winget:BurntSushi.ripgrep.MSVC。不传任何包时默认处理[bootstrap.packages]中配置的全部条目。显式传入包时--manager与显式包会将本次运行限定在这些包范围内见下节源码中的explicit标志。-m, --manager MANAGER只升级该内置或插件管理器名下的包例如--manager brew-cask、--manager mas、--manager winget、--manager apt。可用于共享配置中只想动某一平台/管理器子集的情况也可与system_packages.managers设置见下文“相关配置”配合实现平台差异化。-n, --dry-run打印将会运行的命令而不实际执行用于升级前审查计划。对 brew-cask 等场景dry-run 还会报告“将替换/跳过”的决策但不真正替换应用。-y, --yes跳过确认提示适合 CI、容器等非交互环境。注意--yes只跳过 mise 自己的确认不提供 sudo 凭据。-h, --help打印帮助信息。与其他命令的标志差异对比同样共享驱动循环的apply文档见 docs/cli/bootstrap/packages/apply.mdapply额外提供--update标志apk 加--update-cache、apt 执行apt-get update、winget 执行source update。而upgrade没有独立的--update标志——因为升级本身就会刷新元数据陈旧的包列表会让升级变成静默的空操作因此升级自带刷新。实战示例# 升级配置中的全部已安装包每个可用的管理器都会参与 mise bootstrap packages upgrade # 显式升级单个包不必写入配置 mise bootstrap packages upgrade brew:postgresql17 # 只升级 brew-cask 管理器的 cask mise bootstrap packages upgrade --manager brew-cask # 只升级 Mac App Store 应用 mise bootstrap packages upgrade --manager mas # 只升级 Windows 包 mise bootstrap packages upgrade --manager winget # 非交互式升级 apt 包 mise bootstrap packages upgrade --manager apt --yes # 先审查将要执行的命令 mise bootstrap packages upgrade --dry-run典型的日常维护流程mise bootstrap packages status # 查看主机包当前状态 mise bootstrap packages upgrade --dry-run # 审查升级计划 mise bootstrap packages upgrade # 执行升级源码剖析upgrade 的执行链路命令实现位于 src/cli/system/upgrade.rs核心结构体SystemUpgrade持有packages、manager、dry_run、yes四个字段对应上文参数与标志。执行链路分三步解析目标集合若未传包通过system::packages_from_config(config)读取[bootstrap.packages]的全部条目若显式传包则用system::packages_from_specs_with_config(self.packages, Some(config))解析manager:package规格。两种路径都会先加载Config。构造驱动选项DriverOpts中值得注意的两个字段explicit: !self.packages.is_empty()——显式传包时不可用的管理器会变成硬错误而非静默跳过避免跨平台共享配置在显式请求时“说谎”update: false——注释明确说明“upgrades refresh metadata themselves (stale lists would make them silent no-ops), so no separate --update flag”。调用共享驱动driver::run(mgrs, Action::Upgrade, opts)其中Action::Upgrade的动词为upgrade。共享驱动位于 src/cli/system/driver.rs对Action::Upgrade的关键逻辑跳过缺失包目标过滤条件为“不是 Missing 且不是 Unavailable”的状态统计缺失数量并警告N package(s) not installed — run mise bootstrap packages apply first与命令文档描述一致。跳过不可满足的 pinif !mp.manager.supports_version_pins()时带 pin 的条目被剔除并警告cannot upgrade pinned version ..., skipping——对应文档中“brew、brew-cask、flatpak、flatpak-user、mas、AUR、pacman 无法安装 pin故带 pin 条目被跳过并警告”的行为。结果核对升级前记录每个包的当前版本prior映射调用mp.manager.upgrade(targets, opts)后重新查询installed(targets)只报告实际发生变化的版本如postgresql17 17.2 - 17.3无变化时输出already up to date。管理器自身会对已是最新的包空操作。确认提示非 dry-run、未传--yes且处于交互终端时先弹确认upgrade 包列表?。--manager过滤与错误请求的管理器不在配置中时报no packages requested for manager name若被system_packages.managers设置排除则报manager name is excluded by the system_packages.managers setting。驱动内置的单元测试explicit_packages_reject_unavailable_entries_but_manager_filters_skip_themsrc/cli/system/driver.rs验证了显式包与--manager过滤在“不可用”处理上的差异。另外整个运行通过OperationScope::wrap(bootstrap packages upgrade, ...)包裹见 src/cli/system/upgrade.rs意味着与 bootstrap 其他变更一样会记录历史检查点dry-run 不记录。版本固定pin在升级中的语义升级对 pin 的处理分为三类理解这一点可以避免误判升级时尊重 pinapk、apt、dnf 会将 pin 以管理器原生语法传递给升级命令保证升级后的版本符合配置要求。例如apt:curl 8.5.0-2ubuntu10会通过nameversion传递。升级时跳过 pin 并警告aur、pacman、brew、brew-cask、flatpak、flatpak-user、mas 无法安装固定版本其仓库/机制只暴露最新版本带 pin 的条目在升级时被跳过并给出警告status仍会为它们报告version mismatch。latest的特殊性latest接受任何已安装版本不会在apply时触发升级把它推向最新可用版本正是upgrade的职责。pin 应选择目标机器仓库中实际可用的版本apt 可用apt-cache policy curl检查apk 可用apk policy zlib-devdnf 需选择目标发行版启用的仓库中的版本。mise 不会把包管理器变成历史包存档。相关配置managers 子集与 sudo 行为system_packages.managers默认情况下mise 会对当前机器上可用的每个配置管理器执行操作可用性检查支持平台与所需命令不是“首选管理器”的选择。当一台机器装有多个包管理器、或共享配置列出了本机不需要的管理器时可用system_packages.managers限定子集定义见 docs/settings.toml环境变量MISE_SYSTEM_PACKAGES_MANAGERS[settings] system_packages.managers [apt]这同样作用于upgrade被排除的管理器会在驱动中报excluded by the system_packages.managers setting。它可与平台化配置文件mise.macos.toml、mise.linux.toml需以-E/MISE_ENV或auto_env激活组合实现按 OS 的默认值。system_packages.sudoapk、apt、dnf、pacman 的包变更需要 rootmise 在必要时使用 sudo定义见 docs/settings.toml默认true环境变量MISE_SYSTEM_PACKAGES_SUDO。行为分四种情况已是 root容器、CI不 sudo直接运行交互终端如sudo apt-get install ...正常 sudo 提示非交互且无免密 sudomise 报错并打印需手动执行的完整命令绝不挂起等待密码无论哪种情况完整命令行在执行前都会被记录。设置system_packages.sudo false可完全禁止提权mise 会打印命令由你自行执行。Homebrew formula 安装创建 canonical prefix与 cask 安装器也可能需要提权。aur 助手以当前用户构建、自行处理 pacman 提权flatpak-user 用户级安装不需要 root包管理器插件绝不使用 mise 的 sudo 路径。CI 与自动化场景在容器中通常已是 root不会出现提示mise bootstrap packages upgrade --yes配合状态检查做“只检查不安装”的 CI 门禁status --missing在包缺失时退出码为 1见 docs/bootstrap/packages/index.mdmise bootstrap packages status --missing若需要检查 JSON 结构化状态可使用mise bootstrap packages status --json相关命令见 docs/cli/bootstrap/packages/status.md 对应文档路径与mise bootstrap packages子命令列表见 docs/cli/bootstrap/packages.md。在完整机器初始化流程中upgrade通常位于新机器首次mise bootstrap packages apply之后先 apply 补齐缺失包之后例行运行 upgrade 保持已装包最新。完整的mise bootstrap执行顺序内置管理器安装缺失包位于第 3 步工具安装在第 15 步最后运行名为bootstrap的任务见 docs/bootstrap.md。注意事项与最佳实践升级前先 dry-run--dry-run打印将要运行的命令对 brew-cask 还会报告替换决策AUR 的 dry-run 只显示助手调用不会代你审查 PKGBUILDAUR 包是用户提交的构建脚本升级前应审查上游变更见 docs/bootstrap/packages/aur.md。缺失包不会被升级upgrade跳过未安装的包并提示运行apply先apply补齐再upgrade保持最新。滚动发行版注意Arch 官方仅支持全系统pacman -Syumise 的 scoped upgrade 不是其替代品pacman 条目无法 pin 版本。--yes不等于 sudo 凭据--yes只跳过 mise 的确认非交互环境缺少免密 sudo 时会报错并给出可手动执行的命令。brew-cask 升级可能触发 TCC 重新授权替换/Applications下的 app 后需在系统设置中重新授予该应用的无障碍、录屏等权限。共享配置的跨平台行为不可用管理器如 macOS 上的 apt、Linux 上的 mas在普通升级时被跳过而不报错只有显式请求--manager或显式manager:package才会硬失败。从源码结构看这正是explicit标志src/cli/system/upgrade.rs与驱动中unavailable_manager_is_errorsrc/cli/system/driver.rs的设计意图。关联资源主机包体系的整体介绍见 docs/bootstrap/packages/index.mdbrew 管理器的 pour / 升级 / 共存细节见 docs/bootstrap/packages/brew.md各管理器行为对照各自的 apk、apt、aur、dnf、pacman、flatpak、mas、winget 文档。【免费下载链接】misedev tools, env vars, task runner项目地址: https://gitcode.com/GitHub_Trending/mi/mise创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考