• 我们从 5 开始，每次增加 10，这样您可以在其中添加步骤（即使我们不期望有什么东西比系统更重要需要更新……可能是与系统安全相关的？）
• "05" 用于更新系统标准包管理器（apt、……）
• "15" 用于其他包管理器（flatpak、……）
• "25" 用于工具链更新器
• "35" 用于特定语言的包管理器
• "45" 用于您自己用 git 更新的工具
• 没有排名是最后执行的。 根据实现方式，这个排名可能会在未来消失

注意：目前排名只是一种建议，未来我们期望能够并行启动所有具有相同 <RANK> 的包。因此，步骤之间的空间：您可能不想同时运行多个CPU密集型的打包器。

安装

cargo install --locked system-updater

您还需要一些配置，以便程序知道要执行什么。您可以在git仓库中找到最新的配置示例 在这里。

cd /tmp
curl -O "https://framagit.org/Zykino/system-updater/-/archive/master/system-updater-master.tar.gz?path=example_packagers"
tar -xzf system-updater-master.tar.gz\?path=example_packagers
# On most systems:
mv system-updater-master-example_packagers/example_packagers/ $HOME/.config/systemupdater/packagers

变更日志

在0.1.0版本中

• 运行不同配置文件中找到的命令
• 在升级前后执行预/后命令
• 完成所有安装，并在最后总结成功和错误
• 改进错误 ^^'
• 打包器的执行者需要按顺序执行，并且只有在所有前一个执行失败时才执行
  • 在尝试执行之前，是否可以用 which（该包？）测试命令是否存在？（特别是具有管理员权限时）
• 文档
  • README

路线图

这是无序的。遵循我的动机和PR？

• 测试
• 添加一个 --no-continue -K 参数，在第一个错误时停止
• 添加选项以显示完整配置（所有执行者和它们是否可用或找不到），以及计算配置（仅包含将要使用的执行者）。
• 防止使用 sudo 和等效的，添加一个配置来指定 "需要管理员权限" 或 "以...执行" == sudo <username>
• 命令的并行执行
  • 显示通用进度条和正在执行的任务列表（包括它们的步骤号）："helix PostInstall (1/2)"
  • 应防止所有输入（甚至请求 sudo 的密码）
  • 所有输出（标准和错误）需要重定向到文件。可能像这样：/tmp/system-updater/--<executorName?/stepNumber??>.log
    • 我认为每个命令或执行者都有一个单独的文件，其中包含stdout和stderr是最佳的，可能在每个行前加上 "stdout: "
    • 为人类立即检查日志，一个临时文件夹很棒，但我们可能想要一种方法来存档日志（至少提供一个选项来选择其他目标文件夹）
• 在远程计算机上执行
  • 具有与并行执行相同的子任务，用于UI
  • 从远程机器检索日志（包括正常和错误日志）
• 文档
  • 代码
• 添加CI
• 找到一种方法来分发 "example_packagers" 配置文件夹。使用 cargo parcel？一个 --dump 选项？其他什么？

想要拥有的功能

• 作为一个库使用（我在main.rs中设置了可能的最小值，但接口还没有设计出来）
  • 给出一个目录和/或文件列表
  • 给出一个已经填充的 Updater 结构体
• 有子命令以交互方式对打包器的配置进行操作
  • 列表
  • 显示
  • 创建
  • 删除
  • 更新？（糟糕的方法：显示 + 删除 + 创建？ ^^'）
• 更多配置示例
  • 为所有/大多数著名的系统提供系统执行者（openSUSE，Fedora，Arch，…）
  • 至少提供一个二进制文件下载示例（curl或wget）
• 以更合理的方式启动自身和子命令（不确定是否在所有系统上或以相同的方式进行）