fix: add missing DTK core binary packages to build dependencies

[18202781743]

Added libdtkcore5-bin and libdtk6core-bin to Build-Depends in debian/
control file. These packages were missing but required for the build
process when DTK5 or DTK6 is enabled. The build was failing due to
missing binary dependencies needed for DTK core functionality during
compilation.

Influence:

1. Test building the package with both DTK5 and DTK6 configurations
2. Verify the build process completes successfully without missing
   dependency errors
3. Test building with nodtk5 and nodtk6 flags to ensure conditional
   dependencies work correctly
4. Check that all build tools and binaries are available during
   compilation

fix: 添加缺失的DTK核心二进制包到构建依赖

在debian/control文件的Build-Depends中添加了libdtkcore5-bin和libdtk6core-
bin包。这些包在启用DTK5或DTK6时是必需的，但在构建依赖中缺失。由于编译过
程中缺少DTK核心功能所需的二进制依赖，导致构建失败。

Influence:

1. 测试使用DTK5和DTK6配置构建软件包
2. 验证构建过程能成功完成，没有缺少依赖的错误
3. 测试使用nodtk5和nodtk6标志构建，确保条件依赖正常工作
4. 检查编译期间所有构建工具和二进制文件是否可用

[github-actions]

Warning

[Debian检查]

• 检测到debian目录文件有变更: debian/control

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: 18202781743

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• debian/deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: 18202781743

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• debian/deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[github-actions]

Warning

[Debian检查]

• 检测到debian目录文件有变更: debian/control

[18202781743]

/forcemerge

[deepin-bot]

This pr force merged! (status: blocked)

[deepin-ci-robot]

deepin pr auto review

这段用户希望我审查一个 debian/control 文件的 git diff。
该 diff 修改了 Build-Depends 和 Depends 字段。

对 Diff 的分析：

1. Build-Depends 修改：

   • 添加了 libdtkdata。
   • 为 <!nodtk5> profile 添加了 libdtkcore5-bin。
   • 为 <!nodtk6> profile 添加了 libdtk6core-bin。

2. Depends 修改：

   • 从 libdtk6gui 的 Depends 中移除了 libdtkdata。
   • 从 libdtkgui5 的 Depends 中移除了 libdtkdata。

逻辑与正确性：

• 构建依赖 vs 运行时依赖：

  • 将 libdtkdata 从运行时依赖（libdtk6gui、libdtkgui5）移动到构建依赖（源包）意味着 libdtkdata 仅在编译/链接阶段需要，而不需要在运行时动态链接。
  • 检查： libdtkgui 是否链接到 libdtkdata？通常，如果库链接到另一个库，该库需要在运行时存在。如果 libdtkdata 提供仅头文件的功能，或者如果 libdtkgui 以前静态链接它（在 Debian 策略中不太可能，但有可能），或者如果依赖关系之前是错误的，那么这个更改是有效的。
  • 假设： 如果 libdtkgui 使用 libdtkdata 提供的符号，它必须在运行时依赖它。从 Depends 中移除它表明 libdtkdata 可能是一个仅头文件的库，或者链接行为发生了变化，或者之前的依赖是错误的。然而，标准做法建议如果库链接到共享库，它应该在其 Depends 中列出它（通常通过 ${shlibs:Depends}）。
  • 关键观察： diff 显示 libdtkdata 被添加到 Build-Depends 中。它从 Depends 中显式移除。如果 libdtkdata 是一个共享库，dh_shlibdeps 会自动将其添加到 ${shlibs:Depends}。如果它正从显式列表中移除，这意味着要么：
    1. 它现在通过 ${shlibs:Depends 自动处理（如果之前是手动添加的，这是正确的）。
    2. 它实际上没有在运行时链接（如果是共享库，这很奇怪）。
    3. 它是一个仅头文件库或构建工具。

• 二进制包添加 (libdtkcore5-bin、libdtk6core-bin)：

  • 这些被添加到 Build-Depends 中。-bin 包通常包含可执行文件/工具。添加它们到构建依赖是合理的，如果构建过程需要这些工具（例如，代码生成、资源处理）。

• 语法：

  • Debian 控制文件的语法看起来是正确的（逗号分隔，profile 括号）。

安全、性能、质量：

• 质量：

  • 依赖关系似乎正在被优化或修正。
  • 移除显式的 libdtkdata 运行时依赖：如果 libdtkgui 实际上链接了 libdtkdata，确保 dh_shlibdeps 正确运行以将其包含在 ${shlibs:Depends} 中是至关重要的。如果它被移除且不在 ${shlibs:Depends} 中，那么当调用 libdtkdata 中的符号时，应用程序将会崩溃（未定义的符号）。
  • 建议： 验证 libdtkdata 是否是共享库。如果是，验证 libdtkgui 是否链接到它。如果是，它必须存在于 ${shlibs:Depends} 中。如果 diff 仅移除了手动条目，依赖它由自动生成器处理，那是好的。如果它移除了它且自动生成器没有捕获它，那就是一个 Bug。

• 安全：

  • 依赖关系变更本身并不直接引入安全问题，除非 libdtkdata 包含在运行时加载的插件所需的关键代码，而该代码现在缺失（导致崩溃/DoS）。

• 性能：

  • 构建依赖项的增加可能会略微增加构建时间或镜像大小，但通常是必要的。

构建回复：

1. 总结： 承认更改涉及移动依赖关系（libdtkdata）和添加二进制工具（libdtkcore-bin）。
2. 语法/逻辑：
   • 确认语法正确。
   • 分析 libdtkdata 的移动。解释从运行时依赖移动到构建依赖的含义。
   • 关键检查： libdtkdata 是一个共享库吗？如果是，它是否通过 ${shlibs:Depends} 自动处理？如果手动移除但未被自动捕获，则存在运行时错误的风险。
3. 代码质量：
   • 添加 -bin 包表明构建过程需要工具。这是良好的做法（显式优于隐式）。
   • 如果依赖关系现在是自动生成的，清理 Depends 是良好的做法。
4. 性能/安全：
   • 标准的打包注意事项。
5. 改进建议：
   • 验证 libdtkdata 链接。
   • 检查 dh_shlibdeps 输出。

完善“libdtkdata”观点：
Diff 显示：

• Depends: ..., libdtkdata, -> Depends: ...,
  这移除了硬编码的依赖。
  如果 libdtkgui 链接到 libdtkdata.so，dh_shlibdeps 会将其添加到 ${shlibs:Depends}。
  所以，如果之前的维护者手动添加了它，而现在他们正在清理以依赖 debhelper 的魔法，这是正确的。
  然而，如果 libdtkdata 不是一个共享库（例如，它是一个数据包或仅头文件库），那么它可能根本不应该在 ${shlibs:Depends} 中。但通常，名称 libdtkdata 暗示一个共享库。
  如果它是一个共享库并且被移除，且没有出现在 ${shlibs:Depends} 中，应用程序将会崩溃。
  因此，主要建议是验证 libdtkdata 是否被链接。

完善“-bin”包观点：
添加 libdtkcore5-bin 和 libdtk6core-bin。这些通常包含像 dtk-settings 或类似的工具。如果构建系统运行这些工具来生成文件，这是必需的。逻辑似乎合理。

格式：
使用要求的格式：语法逻辑，代码质量，代码性能，代码安全。

起草内容（思维沙盒）：

• 语法： 有效。
• 逻辑：
  • libdtkdata 移动：从运行时移至构建。这暗示 libdtkgui 可能不再直接链接它，或者依赖关系正在被自动化。警告： 如果它仍然链接，确保 ${shlibs:Depends} 捕获它。
  • libdtkcore*-bin：添加到构建依赖。对于需要工具的构建来说逻辑合理。
• 质量： 清理显式依赖以使用 ${shlibs:Depends} 是“最佳实践”，前提是自动检测有效。
• 安全： 如果依赖关系缺失，存在潜在的 ABI 兼容性风险。
• 性能： 无显著影响。

中文回复的最终润色：
确保像 "Build-Depends"、"Depends"、"shlibs:Depends" 这样的术语被正确使用或解释。

让我们再次检查 diff 上下文。
Package: libdtk6gui ... Depends: ... libdtkdata 被移除。
Package: libdtkgui5 ... Depends: ... libdtkdata 被移除。
Build-Depends ... 添加了 libdtkdata。

这看起来像是一个重构，其中 libdtkdata 被认为是构建时依赖（也许用于生成代码或头文件），而不是运行时链接依赖，或者运行时链接是间接的，或者运行时依赖是错误的。
等等，如果 libdtkdata 在 Build-Depends 中，这意味着构建环境需要它。
如果它从 Depends 中移除，意味着安装后的二进制文件不需要它。
如果 libdtkgui 是一个库，且它使用了 libdtkdata 中的类型，通常它需要链接到它。
如果它确实链接到它，libdtkdata 必须在 Depends 中。
如果 diff 移除了显式条目，它依赖于 ${shlibs:Depends}。
如果 libdtkdata 是一个纯头文件库（不太可能以 lib 开头但有可能），那么将其保留在构建依赖中是可以的。
鉴于名称 libdtkdata，它听起来像是一个共享库。
我将强调检查 libdtkgui 是否链接到 libdtkdata。

回复结构：

1. 总体评价：看起来像是一个依赖关系清理和构建工具补充。
2. 语法逻辑：语法有效。逻辑审查集中在 libdtkdata 的移动上。
3. 代码质量：显式依赖与自动依赖。
4. 代码性能：不适用。
5. 代码安全：依赖解析安全性。
6. 改进意见：验证链接，检查符号。

让我们撰写回复。这份 debian/control 文件的 diff 修改了包的构建依赖（Build-Depends）和运行时依赖（Depends）。主要涉及将 libdtkdata 从运行时依赖移至构建依赖，并新增了 libdtkcore 的二进制工具包作为构建依赖。

以下是对该 diff 的详细审查意见：

1. 语法逻辑

• 语法正确性：diff 中的修改符合 Debian 控制文件的语法规范。字段名、包名、架构限制符（<!nodtk5> 等）以及多行缩进的写法都是正确的。
• 依赖关系变更逻辑：
  • libdtkdata 的移动：diff 显示将 libdtkdata 从 libdtk6gui 和 libdtkgui5 的 Depends 字段中移除，并将其添加到了源包的 Build-Depends 中。
    • 潜在风险：这表明开发者认为 libdtkdata 仅在编译阶段需要（例如作为头文件或编译工具），而在运行时不需要动态链接。但是，如果 libdtkgui 在运行时实际上链接了 libdtkdata.so，那么从 Depends 中移除它会导致严重的运行时错误（如 symbol lookup error 或程序启动失败）。
    • 自动依赖处理：如果 libdtkdata 是一个共享库，且 libdtkgui 链接了它，通常 dh_shlibdeps 工具会自动将其检测并加入 ${shlibs:Depends} 变量中。如果这次修改是为了去除手动指定的依赖，转而完全依赖 ${shlibs:Depends} 的自动检测，那么逻辑上是合理的；但如果是因为误判不需要运行时依赖而移除，则是逻辑错误。
  • 新增 -bin 包：添加了 libdtkcore5-bin 和 libdtk6core-bin 到 Build-Depends。通常 -bin 后缀的包包含可执行工具。如果构建过程中需要调用这些工具（例如代码生成器、资源编译器），这个逻辑是正确的。

2. 代码质量

• 依赖管理的规范性：
  • 显式 vs 隐式：将 libdtkdata 从显式的 Depends 列表中移除，如果是为了让 ${shlibs:Depends} 自动接管，这提高了代码质量，减少了维护负担（当库版本升级时，自动依赖关系会自动更新）。
  • 建议：确保 debian/rules 中正确调用了 dh_shlibdeps，以便自动计算依赖关系。
• 构建配置的一致性：为 libdtkcore-dev 添加对应的 libdtkcore-bin 是一种好的做法，确保了构建环境的完整性。

3. 代码性能

• 此修改主要涉及打包配置，对最终生成的二进制代码的运行时性能没有直接影响。
• 在构建性能方面，增加 Build-Depends 可能会略微增加构建环境的准备时间和镜像体积，但这是必要的代价。

4. 代码安全

• 依赖缺失风险：如前所述，如果 libdtkgui 运行时依赖 libdtkdata 但未在 Depends 中声明（且未被 ${shlibs:Depends} 捕获），会导致用户安装该包后程序无法运行，属于功能安全/可用性风险。
• 版本控制：diff 中未指定 libdtkdata 的具体版本号。如果构建过程对 libdtkdata 的版本有最低要求，建议在 Build-Depends 中指定版本（例如 libdtkdata (>= 1.2.3)），以防止构建环境版本过低导致编译失败。

5. 改进建议

1. 验证链接关系（最重要）：

   • 请务必检查 libdtk6gui 和 libdtkgui5 编译出的二进制文件是否实际链接了 libdtkdata.so。
   • 验证方法：使用 ldd 命令检查生成的库文件。例如：ldd debian/libdtk6gui/usr/lib/*/libdtk6gui.so.* | grep dtkdata。
   • 结论：如果 ldd 输出中有 libdtkdata，则必须保留在 Depends 中（或者确认 ${shlibs:Depends} 包含了它）。如果 ldd 没有输出，则该修改是安全的。

2. 检查 ${shlibs:Depends} 替换：

   • 如果确认 libdtkgui 链接了 libdtkdata，且意图是依赖自动检测，请构建一次包，检查生成的 .deb 包中的 DEBIAN/control 文件，确认 ${shlibs:Depends} 是否被正确替换为包含 libdtkdata 的具体版本号。

3. 版本约束：

   • 如果 libdtkdata 的 API 在构建期间有特定要求，建议在 Build-Depends 中添加版本约束，例如：libdtkdata (>= x.y.z)。

4. 变更说明：

   • 建议在 debian/changelog 中明确说明此次修改的原因（例如："Move libdtkdata to Build-Depends as it is only used for headers/build-time tools" 或 "Rely on dh_shlibdeps for libdtkdata runtime dependency"），以便后续维护者理解意图。

总结：
这份 diff 的逻辑主要依赖于 libdtkdata 是一个仅构建时依赖。如果 libdtkgui 实际上不动态链接 libdtkdata，那么修改是完美且规范的。如果存在动态链接关系，则该修改会导致运行时崩溃。请务必通过 ldd 验证链接关系。