企业官网建设流程全解析

• 图形学
• 桌面应用

本文以 Krita 仓库packaging/steam/目录下的发布说明与构建脚本为骨架，系统讲解如何将 Krita 桌面版发布到 Steam：从 Steamworks 账号与 SDK 准备、Linux/Windows 构建产物的目录组织，到 SteamPipe App/Depot 构建脚本的编写、steamcmd 命令行推送、分支发布管理，直至面向用户的事件公告。读完你不仅能复现 Krita 官方团队的 Steam 发布流程，还能理解app_build_krita.vdf、depot_build_*.vdf与launch.sh每个字段的实际含义。

概述：Krita 在 Steam 上是怎么跑起来的

Krita 是构建于 KDE 与 Qt 框架之上的开源数字绘画软件，其桌面发行覆盖 Linux 与 Windows 两大平台。Steam 作为游戏分发渠道，对应用内容的组织方式有自己的一套约定（App / Depot / ContentBuilder / SteamPipe），与常规的官网包发布差异很大。

Krita 仓库在 packaging/steam/ 目录下保存了一整套可直接照做的发布资料：

• INSTRUCTIONS.md：Krita 维护者撰写的端到端发布步骤说明（本文的骨架）；
• app_build_krita.vdf：SteamPipe 主构建脚本，声明 AppID、输出目录与各 Depot 的引用；
• depot_build_common.vdf、depot_build_windows.vdf、depot_build_linux.vdf：各 Depot 的内容映射脚本；
• launch.sh：Linux 端绕过 Steam Runtime、直接启动 Krita AppImage 的启动脚本。

这套流程由 Krita 团队在实际发布中沉淀而成，其核心难点集中在两处：一是把 AppImage 跑进 Steam 的启动器（Linux），二是理解 SteamPipe 构建脚本的字段含义。下文按发布执行的先后顺序逐一展开。

第一步：Steamworks 账号与 Steamworks SDK

发布到 Steam 的前提是拥有 Steamworks 合作伙伴账号，并下载 Steamworks SDK。官方完整文档位于 Steamworks SDK 文档站点，其中 SteamPipe 相关内容在 SDK 文档的 uploading 一节，但 Krita 仓库内的 INSTRUCTIONS.md 已经把关键步骤压缩为可直接照做的清单。

Steamworks SDK 支持 Windows 与 Linux（MacOSX 未必可用，Krita 维护者明确表示不确定其兼容性）。SDK 中与发布直接相关的工具链是：

• sdk/tools/ContentBuilder/：内容打包与上传工具集；
• builder/steamcmd.exe（Windows）与builder_linux/steamcmd.sh（Linux）：命令行推送工具；
• sdk/tools/ContentBuilder/content/：存放各平台待发布内容的根目录。

第二步：准备各平台的 Krita 稳定版产物

下载 Krita 的稳定版二进制，并分别放置到 ContentBuilder 的内容目录下。当前 Krita 在 Steam 上只覆盖 Linux 与 Windows 两个平台，因此目录组织为：

sdk/tools/ContentBuilder/content/ ├── linux/ # Linux 构建产物 └── windows/ # Windows 构建产物

Linux：launch.sh + 重命名的 AppImage

Steam 自带一套“linux runtime”，它会在启动应用时注入自己的运行时环境。但 Krita 的 Linux 发行版是 AppImage——AppImage 本身已经打包了完整运行库，Steam Runtime 不但用不上，反而会干扰 AppImage 自带的库解析。因此 Krita 通过一个极简的启动脚本 launch.sh 绕开 Steam Runtime。

launch.sh 的完整内容如下：

#!/bin/bash # Launcher script for running the Krita AppImage inside of the Steam Linux Runtime. # Include alongside krita.AppImage (probably in `content/linux/`) and # configure Steamworks to use this as the default/primary launch option. # Prevent runtime environment or host system libraries from being used over AppImage packaged ones. unset LD_LIBRARY_PATH # UTF-8 Locale support. LC_ALL=en_US.UTF-8 # Prevents Auto-Updates. STARTED_BY_STEAM=1 # Launch Krita. appdir=$(dirname "$0") $appdir/krita.AppImage

脚本要点逐行拆解：

• unset LD_LIBRARY_PATH：清空外部注入的库搜索路径，保证 AppImage 优先使用自身打包的依赖，这是绕过 Steam Runtime 的关键；
• LC_ALL=en_US.UTF-8：强制 UTF-8 区域，保证中文等多语言文本渲染正常；
• STARTED_BY_STEAM=1：通知 Krita 当前由 Steam 启动，用于抑制 Krita 自身的更新提示（避免与 Steam 的更新机制冲突）；
• appdir=$(dirname "$0")+$appdir/krita.AppImage：从脚本所在目录定位并执行 AppImage。

与之配套的约定是：AppImage 必须命名为krita.AppImage，并和launch.sh一起放在content/linux/中。在 Steamworks 后台把launch.sh配置为默认/首选启动项即可。

Windows：便携版目录重命名

Windows 端没有运行时绕过问题。Steam 侧配置的启动路径是相对路径krita\bin\krita.exe，因此 Krita 团队的惯用做法是把便携版构建的整个目录重命名为krita，再放进content/windows/，使目录结构与 Steam 期望的启动路径一致：

sdk/tools/ContentBuilder/content/windows/krita/bin/krita.exe

这个路径约定并非强制，但沿用默认值可以少改一处配置。

第三步：编写 SteamPipe Build Scripts

内容就位后，还不能直接推送——需要先为 Krita 编写 “SteamPipe Build Scripts”。这些脚本会被喂给steamcmd，其中记录了 Krita 的AppID（在 Steamworks 网页后台可查）、内容所在路径、构建输出路径，以及每个 Depot 对应的独立构建脚本。

理解 App 与 Depot 的关系

• App（应用）：Steam 上向用户呈现的单一产品，拥有唯一 AppID；
• Depot（仓库）：Steam 对内容包（package）的称呼，每个 Depot 有唯一的 DepotID。通过 Steamworks 网页界面创建 Depot，通过 Steamworks SDK 推送内容到对应 Depot。

Krita 目前建有 4 个 Depot：Krita Common、Krita Windows、Krita Linux、Krita MacOSX。其中实际使用只有 Windows 与 Linux 两个；Common 与 MacOSX 是为“未来共享公共数据 / 发布 OSX 版”预留的。历史上一度存在过 10～12 个 Depot（早期按平台拆分更细），后来被精简合并。

每个 Depot 对应一份构建脚本，其作用就是告诉 SDK“这个 Depot 的内容在哪里”。例如 Windows Depot 脚本指向content/windows/。

主构建脚本：app_build_krita.vdf

仓库中的 app_build_krita.vdf 是 App 级主脚本模板：

"appbuild" { "appid" "KRITA_APP_ID" // Replace value with Krita's Steam AppID. "desc" "Krita Desktop Steam Update" "buildoutput" "..\output\" // build output folder for .log, .csm & .csd files, relative to location of this file "contentroot" "..\content\" // root content folder, relative to location of this file "setlive" "" // branch to set live after successful build, non if empty "preview" "0" // to enable preview builds "local" "" // set to file path of local content server "depots" { "COMMON_DEPOT_ID" "depot_build_common.vdf" // Replace keys with various Krita depot ID's, as found on Steamworks web interface. "WINDOWS_DEPOT_ID" "depot_build_windows.vdf" "LINUX_DEPOT_ID" "depot_build_linux.vdf" } }

字段含义：

注意depots段中键是 DepotID（占位符），值是相对本脚本的 .vdf 路径。仓库模板用COMMON_DEPOT_ID、WINDOWS_DEPOT_ID、LINUX_DEPOT_ID占位，均需替换为 Steamworks 后台查到的真实数字 ID。

Depot 构建脚本：depot_build_*.vdf

三个 Depot 脚本结构一致，区别仅在LocalPath指向的内容子目录。以 depot_build_linux.vdf 为例：

"DepotBuildConfig" { "DepotID" "LINUX_DEPOT_ID" // Replace value with correct depot ID... // Set a root for all content. // All relative paths specified below (LocalPath in FileMapping entries, and FileExclusion paths) // will be resolved relative to this root. // If you don't define ContentRoot, then it will be assumed to be // the location of this script file, which probably isn't what you want "ContentRoot" "..\content\" // include all files recursively "FileMapping" { // This can be a full path, or a path relative to ContentRoot "LocalPath" ".\linux\*" // This is a path relative to the install folder of your game "DepotPath" "." // If LocalPath contains wildcards, setting this means that all // matching files within subdirectories of LocalPath will also // be included. "recursive" "1" } // but exclude all symbol files // This can be a full path, or a path relative to ContentRoot "FileExclusion" "*.pdb" }

字段说明：

• DepotID：本 Depot 的真实 ID；
• ContentRoot：所有相对路径解析的根目录，注释特别提醒：若缺失则默认取脚本所在目录，这通常不是想要的；
• FileMapping：内容映射块——
  • LocalPath：本地内容路径，可含通配符，.\linux\*表示content/linux/下的全部内容；
  • DepotPath：相对游戏安装目录的目标路径，.表示直接放在安装根目录；
  • recursive：置 1 时递归包含子目录中的所有匹配文件；
• FileExclusion：排除规则，*.pdb用于剔除 Windows 符号文件。

三个 Depot 脚本与目录的对应关系为：

从仓库现状看，content/common/目录目前没有对应产物文件，Common Depot 属于预留性质，与 INSTRUCTIONS.md 中“主要使用 Windows 与 Linux 两个 Depot”的描述一致。

一次性投入：这是整个流程中最繁琐的部分——在 Steamworks 网页后台创建 Depot，再为 App 和每个 Depot 编写构建脚本。但它只需要做一次，之后可以一直保留在本地复用，后续每次发版只改内容、重跑命令即可。

第四步：用 steamcmd 构建并推送

一切就绪后，在SDK 的 ContentBuilder 目录下执行推送命令。Linux 端命令为：

sdk/tools/ContentBuilder/builder_linux/steamcmd.sh +login <STEAM_USERNAME> <STEAM_PASSWORD> +run_app_build_http -desc "Krita Desktop Build" <PATH_TO_APP_BUILD_SCRIPT>

Windows 端使用等价命令（builder/steamcmd.exe）。命令执行后 steamcmd 会：

1. 使用提供的账号密码登录 Steamworks；
2. 解析-desc指定的构建描述；
3. 读取 App 构建脚本，依次构建其中引用的所有 Depot；
4. 将构建产物上传推送至 Steam 内容服务器。

+run_app_build_http使用 HTTP 协议执行构建任务，<PATH_TO_APP_BUILD_SCRIPT>指向第三步写好的app_build_krita.vdf。推送成功后，可以在buildoutput指定的目录查看.log日志与.csm/.csd构建元数据文件。

第五步：分支管理与发布上线

构建推送成功不代表用户能立刻收到更新。要让最新构建真正生效，需要在 Steamworks 网页后台 “SteamPipe” 区域，把default分支指向最新构建。

Krita 团队在分支管理上维护了三条分支：

beta与rollback都是通过 Steam 客户端 GUI 让用户主动选择的（opt-in），不会自动推送给普通用户。

值得一提的是，App 构建脚本中的setlive字段与这一步是联动的：若在app_build_krita.vdf的setlive填入分支名（如default），steamcmd 会在构建成功后将对应分支直接设为 live；模板默认留空，即“只推送、不自动上线”，由发布者在网页后台手动控制上线时机。

第六步：向用户发布更新公告

构建上线后，最后一步是让用户知道更新了什么。通过 Steamworks 网页后台的 “Post/Manage Events & Announcements” 栏目，可以发布更新说明并感谢玩家支持。Krita 每次 Steam 发版都会走这一步，向社区同步本次更新的内容清单。

完整流程速览与常见坑位

按顺序回顾 Krita 的 Steam 发布流程：

1. 注册 Steamworks 账号并下载 Steamworks SDK；
2. 下载 Krita 稳定版二进制，Linux 产物（重命名为krita.AppImage的 AppImage + launch.sh）放入content/linux/，Windows 便携版（目录重命名为krita）放入content/windows/；
3. 编写 app_build_krita.vdf 与三个 depot_build_*.vdf，填上真实 AppID / DepotID；
4. 运行steamcmd.sh +login ... +run_app_build_http -desc "Krita Desktop Build" <PATH_TO_APP_BUILD_SCRIPT>构建并推送；
5. 在 Steamworks 的 SteamPipe 后台将default分支指向最新构建（或用setlive自动上线）；
6. 通过 Events & Announcements 发布更新公告。

发布过程中最容易踩的坑有三个：

• Linux 端 AppImage 被 Steam Runtime 干扰：务必通过unset LD_LIBRARY_PATH的 launch.sh 启动，且 AppImage 必须精确命名为krita.AppImage；
• 路径约定不一致：Windows 启动路径写死为krita\bin\krita.exe，便携版目录必须重命名为krita；所有 VDF 中的相对路径都以脚本所在位置为基准，ContentRoot缺失时会退化为脚本目录导致内容映射错位；
• 构建成功但用户没收到更新：推送 ≠ 上线，必须确认default分支已指向新构建。

延伸阅读

想深入了解 Krita 的跨平台打包体系，可以在仓库中继续探索：

• packaging/linux/appimage/：AppImage 构建脚本（含build-image.sh的签名、.upd_info更新信息写入等），对应 Steam Linux 端的krita.AppImage来源；
• packaging/linux/flatpak/FLATPAK.md：Flatpak 打包说明，可对比不同发行渠道的差异；
• packaging/windows/：Windows 便携版构建与安装器相关脚本；
• packaging/macos/：macOS 打包脚本——对应 Krita 预留的 MacOSX Depot 未来可能的产物来源。

本文所介绍的命令行、目录结构与脚本字段均以当前仓库 packaging/steam/ 的实际内容为准，AppID / DepotID 等敏感值需要在各自的 Steamworks 后台获取后填入占位符。

• 图形学
• 桌面应用