拓冰网站定制 
Proton 版本升级 Rebase 全流程指南从上游 Wine 迁移补丁的工程实践【免费下载链接】ProtonCompatibility tool for Steam Play based on Wine and additional components项目地址: https://gitcode.com/gh_mirrors/pr/Proton导读Proton 是 Steam Play 的兼容工具其核心思路是在 Wine 及其组件如 DXVK、vkd3d-proton、dxvk-nvapi之上叠加大量自定义补丁以满足游戏兼容性需求。每当上游 Wine 发布新版本Proton 维护者都需要执行一次Rebase把散落在旧版本之上的补丁重新应用到新版本分支上同时剔除已经被上游收录的补丁。本文基于 docs/REBASING_TIPS.md系统讲解 Proton 的补丁管理纪律、批量迁移命令、冲突处理脚本与收尾的 prefix 版本号更新机制并给出仓库源码级佐证。读完本文你将掌握一套可复制的 Wine rebase 操作流程。为什么 Proton 需要频繁 RebaseProton 并不是简单的 Wine 发行版它在每个上游版本之上都维护着数量庞大的本地补丁本仓库的wine/目录即内嵌了带补丁的 Wine 源码树此外还有dxvk/、vkd3d-proton/、dxvk-nvapi/、wineopenxr/等配套组件。这些补丁来源有两类已上游化upstreamed已经合入官方 Wine 的补丁纯本地补丁因兼容性、时机等原因只存在于 Proton 中的补丁。Rebase 的核心矛盾在于新版本 Wine 可能已经包含了部分 Proton 补丁的内容直接照搬会冲突或冗余同时纯本地补丁又必须原样保留。因此维护一套能区分两类补丁、可批量迁移、可安全中断续跑的流程是每次升级成败的关键。铁律cherry-pick 必须区分-x参数文档首先强调了 Proton 维护者在 cherry-pick 时的纪律从上游 Winecherry-pick 到 Proton时必须加-x参数这样原始提交 ID 会保留在提交信息中形成可追溯的来自上游标记反之对于没有上游化的补丁绝不使用-x避免留下误导性的上游关联标记。这条纪律的意义在 rebase 时兑现Proton 的提交历史中凡是带有-x标记提交信息中带有 cherry picked from commit ... 字样的提交说明其内容已经在上游存在新版本 rebase 时可以安全丢弃而没有该标记的则是必须继续携带的本地补丁。提交信息本身因此成为 rebase 时的过滤依据。第一步列出需要迁移的补丁清单文档给出了生成待迁移补丁列表的核心命令在 Wine 仓库中执行wine$ git log --prettyoneline --reverse --grepcherry pick --invert-grep wine-4.2..proton_4.2逐段拆解这条命令的语义git log遍历提交历史wine-4.2..proton_4.2范围限定为从 Wine 基线标签wine-4.2之后、到 Proton 分支proton_4.2为止的提交--grepcherry pick--invert-grep排除提交信息中含 cherry pick 字样的提交即排除已上游化、带-x标记的补丁只留下纯本地补丁--prettyoneline --reverse以一行一条的形式输出且按时间正序排列方便后续按顺序逐条应用。执行后得到的列表即当前版本基线之上需要原样迁移的补丁集合。接下来要做的就是把这个列表不带-x逐一 cherry-pick 到新的 Wine release 标签上边应用边解决冲突。第二步用pick_commits脚本批量迁移补丁文档提供了一段精心设计的 bash 脚本pick_commits相比 git 内置的git rebase --onto等手段它更直观、更易配合人工干预#!/bin/bash # Cherry-picks commits from an input file in --prettyoneline format. # Lines that begin with # are ignored. # Aborts when a cherry-pick fails. # Outputs the same input file on stderr, but with # prefixed to lines that were successfully cherry-picked. #Usage: # $ pick_commits to_pick 2 ~/to_pick2 # On pick failure, fix conflicts and use git cherry-pick --continue, or # otherwise fix up the repo as desired. # Edit ~/to_pick2 to comment-out the commit that you fixed. # Continue using the new file: # $ pick_commits to_pick2 2 ~/to_pick # Repeat, alternating between to_pick and to_pick2. broken0 while read -r l; do f$(echo -n $l | cut -d -f1 -) if [ $broken 0 -a ${f:0:1} ! # ]; then echo Picking $l git cherry-pick $f 21 if [ $? -ne 0 ]; then echo $l 12 broken1 else echo #$l 12 fi else echo $l 12 fi done $1脚本工作机制解读输入一个--prettyoneline格式的补丁列表文件即第一步命令的输出注释行跳过以#开头的行被忽略用于标记已处理/已放弃的提交顺序执行逐行取出提交哈希cut -d -f1取第一个以空格分隔的字段执行git cherry-pick失败即停一旦某个 cherry-pick 失败$? -ne 0把该行原样输出到 stderr 并置broken1终止后续操作避免冲突雪崩成功即标记成功 picked 的提交向 stderr 输出时前缀一个#实现处理进度即清单更新。标准用法与冲突处理循环脚本设计成两文件交替的工作流配合 stderr 重定向实现进度持久化$ pick_commits to_pick 2 ~/to_pick2 # 若中途失败 # 1. 手动解决冲突后执行 git cherry-pick --continue或以其他方式修复仓库状态 # 2. 编辑 ~/to_pick2把刚才失败的那条提交行加 # 注释掉 # 3. 用新文件继续 $ pick_commits to_pick2 2 ~/to_pick # 如此往复在 to_pick 与 to_pick2 之间交替直到清单全部处理完毕成功被 pick 的提交会以#开头写回新文件下次运行时自动跳过失败提交被手动注释后其余未处理提交可以继续执行做到任意断点续跑由于脚本输出处理后的清单到 stderr、原始日志到 stdout重定向互不干扰文件内容始终是剩余任务 已完成标记的完整快照。第三步Rebase 完成后更新 prefix 版本号文档明确指出收尾动作Wine rebase 完成后更新 proton Python 脚本中的 prefix 版本号并把 minor 版本重置回 1。这一要求在仓库源码中得到了完整印证。在 proton 脚本第 44 行CURRENT_PREFIX_VERSION11.0-100prefix 版本号采用主版本.次版本-前缀号的结构例如11.0-100。其作用体现在两个关键机制上prefix 版本持久化setup_prefix()在 proton 中读取pfx/version文件获得旧版本号初始化完成后在 proton 将CURRENT_PREFIX_VERSION写入该文件升级判定upgrade_pfx()在 proton 中若旧版本号与CURRENT_PREFIX_VERSION不一致即触发 prefix 升级逻辑并打印Upgrading prefix from 旧版本 to 新版本日志。正因为每次启动都会比对版本号每次 rebase 到新 Wine 后都必须提升该版本号否则旧的 prefix 不会得到重新初始化新的 Wine/DLL 行为也不会生效。而重置 minor 版本指的是当主版本发生跨越例如从4.11升到5.0时把-之后的子版本号从累加值重新置为1如4.11-2→5.0-1从而形成清晰的大版本归零、小版本递增的节奏。源码中还能看到版本号比较的实际逻辑proton脚本会将旧版本.旧前缀号与新版本.新前缀号逐一按主版本、次版本比较若发现当前运行的 Proton 版本低于 prefix 记录版本会判定为降级场景输出Removing newer prefix并清理由旧版本创建的 tracked files 后重建 prefix——这意味着不正确地回退 prefix 版本号会导致 prefix 被重建用户数据迁移成本很高进一步说明版本号管理必须谨慎。与 Rebase 密切相关的仓库资产执行 rebase 时以下仓库资产值得配合使用wine/内嵌的 Wine 源码树rebase 的主战场dxvk/、vkd3d-proton/、dxvk-nvapi/、wineopenxr/配套图形与接口组件其版本往往与 Wine 版本联动rebase 时通常需要同步升级proton启动与 prefix 管理入口CURRENT_PREFIX_VERSION的所在地proton_3.7_tracked_files历史版本遗留的 tracked files 清单供旧 prefix 升级路径使用见 proton 中对 3.7 旧 prefix 的特殊处理Makefile.in 与 Makefile构建入口确认 rebase 后各组件版本一致性docs/REBASING_TIPS.md本文所依据的官方操作文档建议直接对照阅读。此外Proton 的构建和打包依赖 Docker 多阶段镜像见 docker/proton.Dockerfile.in其中 Wine 与 LLVM、Mingw 工具链的版本组合也需要在 rebase 时一并核对必要时参考 docker/README.md 调整镜像构建参数。总结一次完整的 Proton Rebase 可以归纳为四个步骤区分补丁来源cherry-pick 上游补丁一律加-x本地补丁一律不加让提交信息自带可丢弃标记生成迁移清单用git log --grepcherry pick --invert-grep反向筛选出必须携带的本地补丁批量应用借助pick_commits脚本按清单逐条 cherry-pick冲突时修复后交替使用两份清单文件续跑更新版本号在 proton 中提升CURRENT_PREFIX_VERSION并将 minor 重置为 1触发 prefix 升级使新 Wine 行为生效。这套流程的核心价值在于用统一的提交标记纪律 可断点续跑的工具脚本 自动触发的 prefix 升级机制把升级上游版本这件高频、高风险的事变成可控、可复现的工程操作。【免费下载链接】ProtonCompatibility tool for Steam Play based on Wine and additional components项目地址: https://gitcode.com/gh_mirrors/pr/Proton创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Proton 版本升级 Rebase 全流程指南：从上游 Wine 迁移补丁的工程实践
Proton 版本升级 Rebase 全流程指南从上游 Wine 迁移补丁的工程实践【免费下载链接】ProtonCompatibility tool for Steam Play based on Wine and additional components项目地址: https://gitcode.com/gh_mirrors/pr/Proton导读Proton 是 Steam Play 的兼容工具其核心思路是在 Wine 及其组件如 DXVK、vkd3d-proton、dxvk-nvapi之上叠加大量自定义补丁以满足游戏兼容性需求。每当上游 Wine 发布新版本Proton 维护者都需要执行一次Rebase把散落在旧版本之上的补丁重新应用到新版本分支上同时剔除已经被上游收录的补丁。本文基于 docs/REBASING_TIPS.md系统讲解 Proton 的补丁管理纪律、批量迁移命令、冲突处理脚本与收尾的 prefix 版本号更新机制并给出仓库源码级佐证。读完本文你将掌握一套可复制的 Wine rebase 操作流程。为什么 Proton 需要频繁 RebaseProton 并不是简单的 Wine 发行版它在每个上游版本之上都维护着数量庞大的本地补丁本仓库的wine/目录即内嵌了带补丁的 Wine 源码树此外还有dxvk/、vkd3d-proton/、dxvk-nvapi/、wineopenxr/等配套组件。这些补丁来源有两类已上游化upstreamed已经合入官方 Wine 的补丁纯本地补丁因兼容性、时机等原因只存在于 Proton 中的补丁。Rebase 的核心矛盾在于新版本 Wine 可能已经包含了部分 Proton 补丁的内容直接照搬会冲突或冗余同时纯本地补丁又必须原样保留。因此维护一套能区分两类补丁、可批量迁移、可安全中断续跑的流程是每次升级成败的关键。铁律cherry-pick 必须区分-x参数文档首先强调了 Proton 维护者在 cherry-pick 时的纪律从上游 Winecherry-pick 到 Proton时必须加-x参数这样原始提交 ID 会保留在提交信息中形成可追溯的来自上游标记反之对于没有上游化的补丁绝不使用-x避免留下误导性的上游关联标记。这条纪律的意义在 rebase 时兑现Proton 的提交历史中凡是带有-x标记提交信息中带有 cherry picked from commit ... 字样的提交说明其内容已经在上游存在新版本 rebase 时可以安全丢弃而没有该标记的则是必须继续携带的本地补丁。提交信息本身因此成为 rebase 时的过滤依据。第一步列出需要迁移的补丁清单文档给出了生成待迁移补丁列表的核心命令在 Wine 仓库中执行wine$ git log --prettyoneline --reverse --grepcherry pick --invert-grep wine-4.2..proton_4.2逐段拆解这条命令的语义git log遍历提交历史wine-4.2..proton_4.2范围限定为从 Wine 基线标签wine-4.2之后、到 Proton 分支proton_4.2为止的提交--grepcherry pick--invert-grep排除提交信息中含 cherry pick 字样的提交即排除已上游化、带-x标记的补丁只留下纯本地补丁--prettyoneline --reverse以一行一条的形式输出且按时间正序排列方便后续按顺序逐条应用。执行后得到的列表即当前版本基线之上需要原样迁移的补丁集合。接下来要做的就是把这个列表不带-x逐一 cherry-pick 到新的 Wine release 标签上边应用边解决冲突。第二步用pick_commits脚本批量迁移补丁文档提供了一段精心设计的 bash 脚本pick_commits相比 git 内置的git rebase --onto等手段它更直观、更易配合人工干预#!/bin/bash # Cherry-picks commits from an input file in --prettyoneline format. # Lines that begin with # are ignored. # Aborts when a cherry-pick fails. # Outputs the same input file on stderr, but with # prefixed to lines that were successfully cherry-picked. #Usage: # $ pick_commits to_pick 2 ~/to_pick2 # On pick failure, fix conflicts and use git cherry-pick --continue, or # otherwise fix up the repo as desired. # Edit ~/to_pick2 to comment-out the commit that you fixed. # Continue using the new file: # $ pick_commits to_pick2 2 ~/to_pick # Repeat, alternating between to_pick and to_pick2. broken0 while read -r l; do f$(echo -n $l | cut -d -f1 -) if [ $broken 0 -a ${f:0:1} ! # ]; then echo Picking $l git cherry-pick $f 21 if [ $? -ne 0 ]; then echo $l 12 broken1 else echo #$l 12 fi else echo $l 12 fi done $1脚本工作机制解读输入一个--prettyoneline格式的补丁列表文件即第一步命令的输出注释行跳过以#开头的行被忽略用于标记已处理/已放弃的提交顺序执行逐行取出提交哈希cut -d -f1取第一个以空格分隔的字段执行git cherry-pick失败即停一旦某个 cherry-pick 失败$? -ne 0把该行原样输出到 stderr 并置broken1终止后续操作避免冲突雪崩成功即标记成功 picked 的提交向 stderr 输出时前缀一个#实现处理进度即清单更新。标准用法与冲突处理循环脚本设计成两文件交替的工作流配合 stderr 重定向实现进度持久化$ pick_commits to_pick 2 ~/to_pick2 # 若中途失败 # 1. 手动解决冲突后执行 git cherry-pick --continue或以其他方式修复仓库状态 # 2. 编辑 ~/to_pick2把刚才失败的那条提交行加 # 注释掉 # 3. 用新文件继续 $ pick_commits to_pick2 2 ~/to_pick # 如此往复在 to_pick 与 to_pick2 之间交替直到清单全部处理完毕成功被 pick 的提交会以#开头写回新文件下次运行时自动跳过失败提交被手动注释后其余未处理提交可以继续执行做到任意断点续跑由于脚本输出处理后的清单到 stderr、原始日志到 stdout重定向互不干扰文件内容始终是剩余任务 已完成标记的完整快照。第三步Rebase 完成后更新 prefix 版本号文档明确指出收尾动作Wine rebase 完成后更新 proton Python 脚本中的 prefix 版本号并把 minor 版本重置回 1。这一要求在仓库源码中得到了完整印证。在 proton 脚本第 44 行CURRENT_PREFIX_VERSION11.0-100prefix 版本号采用主版本.次版本-前缀号的结构例如11.0-100。其作用体现在两个关键机制上prefix 版本持久化setup_prefix()在 proton 中读取pfx/version文件获得旧版本号初始化完成后在 proton 将CURRENT_PREFIX_VERSION写入该文件升级判定upgrade_pfx()在 proton 中若旧版本号与CURRENT_PREFIX_VERSION不一致即触发 prefix 升级逻辑并打印Upgrading prefix from 旧版本 to 新版本日志。正因为每次启动都会比对版本号每次 rebase 到新 Wine 后都必须提升该版本号否则旧的 prefix 不会得到重新初始化新的 Wine/DLL 行为也不会生效。而重置 minor 版本指的是当主版本发生跨越例如从4.11升到5.0时把-之后的子版本号从累加值重新置为1如4.11-2→5.0-1从而形成清晰的大版本归零、小版本递增的节奏。源码中还能看到版本号比较的实际逻辑proton脚本会将旧版本.旧前缀号与新版本.新前缀号逐一按主版本、次版本比较若发现当前运行的 Proton 版本低于 prefix 记录版本会判定为降级场景输出Removing newer prefix并清理由旧版本创建的 tracked files 后重建 prefix——这意味着不正确地回退 prefix 版本号会导致 prefix 被重建用户数据迁移成本很高进一步说明版本号管理必须谨慎。与 Rebase 密切相关的仓库资产执行 rebase 时以下仓库资产值得配合使用wine/内嵌的 Wine 源码树rebase 的主战场dxvk/、vkd3d-proton/、dxvk-nvapi/、wineopenxr/配套图形与接口组件其版本往往与 Wine 版本联动rebase 时通常需要同步升级proton启动与 prefix 管理入口CURRENT_PREFIX_VERSION的所在地proton_3.7_tracked_files历史版本遗留的 tracked files 清单供旧 prefix 升级路径使用见 proton 中对 3.7 旧 prefix 的特殊处理Makefile.in 与 Makefile构建入口确认 rebase 后各组件版本一致性docs/REBASING_TIPS.md本文所依据的官方操作文档建议直接对照阅读。此外Proton 的构建和打包依赖 Docker 多阶段镜像见 docker/proton.Dockerfile.in其中 Wine 与 LLVM、Mingw 工具链的版本组合也需要在 rebase 时一并核对必要时参考 docker/README.md 调整镜像构建参数。总结一次完整的 Proton Rebase 可以归纳为四个步骤区分补丁来源cherry-pick 上游补丁一律加-x本地补丁一律不加让提交信息自带可丢弃标记生成迁移清单用git log --grepcherry pick --invert-grep反向筛选出必须携带的本地补丁批量应用借助pick_commits脚本按清单逐条 cherry-pick冲突时修复后交替使用两份清单文件续跑更新版本号在 proton 中提升CURRENT_PREFIX_VERSION并将 minor 重置为 1触发 prefix 升级使新 Wine 行为生效。这套流程的核心价值在于用统一的提交标记纪律 可断点续跑的工具脚本 自动触发的 prefix 升级机制把升级上游版本这件高频、高风险的事变成可控、可复现的工程操作。【免费下载链接】ProtonCompatibility tool for Steam Play based on Wine and additional components项目地址: https://gitcode.com/gh_mirrors/pr/Proton创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考