refactor: unify dtk5 and dtk6 version handling

[18202781743]

Removed version mapping logic for DTK5 and DTK6 as part of unified build
transformation. The changes include:

1. Removed DTK5_VERSION, DTK6_VERSION, and DTK5_MAJOR_MINOR variable
   definitions
2. Removed VERSION, PACK_VER, and BUILD_VER variable definitions
3. Removed -DBUILD_VERSION and -DDTK_VERSION CMake arguments from both
   DTK5 and DTK6 build configurations
4. Removed override_dh_makeshlibs target that used version-specific
   dependency specifications

This refactoring is necessary because dtk5 and dtk6 now share the same
version numbers, eliminating the need for separate version mapping
logic. The unified build approach simplifies the build system and
reduces maintenance complexity.

Influence:

1. Verify that both DTK5 and DTK6 packages build successfully without
   version mapping
2. Test that the resulting packages have correct version numbers
3. Check that shared library dependencies are properly handled without
   version-specific overrides
4. Validate that Build-Profiles (nodtk5, nodtk6, nodoc) still work
   correctly
5. Test package installation and runtime functionality

refactor: 统一dtk5和dtk6版本处理逻辑

作为统一构建改造的一部分，移除了DTK5和DTK6的版本映射逻辑。具体变更包括：

1. 移除了DTK5_VERSION、DTK6_VERSION和DTK5_MAJOR_MINOR变量定义
2. 移除了VERSION、PACK_VER和BUILD_VER变量定义
3. 从DTK5和DTK6构建配置中移除了-DBUILD_VERSION和-DDTK_VERSION CMake参数
4. 移除了使用版本特定依赖规范的override_dh_makeshlibs目标

此次重构是必要的，因为dtk5和dtk6现在使用相同的版本号，不再需要单独的版本
映射逻辑。统一构建方法简化了构建系统并降低了维护复杂度。

Influence:

1. 验证DTK5和DTK6包在没有版本映射的情况下能否成功构建
2. 测试生成的包是否具有正确的版本号
3. 检查共享库依赖关系在没有版本特定覆盖的情况下是否正确处理
4. 验证Build-Profiles（nodtk5、nodtk6、nodoc）是否仍能正常工作
5. 测试软件包安装和运行时功能

Summary by Sourcery

Unify DTK5 and DTK6 version handling in the Debian packaging by removing obsolete version mapping and custom version arguments from the build rules.

Enhancements:

• Simplify Debian build rules by dropping separate DTK5/DTK6 version variables and derived VERSION/PACK_VER/BUILD_VER values.
• Remove CMake build arguments related to custom build and DTK versions now that DTK5 and DTK6 share the same versioning scheme.
• Eliminate the override_dh_makeshlibs target that imposed version-specific shared library dependency handling in favor of the default behavior.

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Refactors the Debian packaging rules to remove DTK5/DTK6-specific version mapping and related build-time variables/overrides, relying instead on unified versioning and default dependency handling for both build variants.

File-Level Changes

Change	Details	Files
Remove DTK5/DTK6-specific version variables now that both share the same versioning scheme.	Delete DTK5_VERSION and DTK6_VERSION variable definitions used to map or derive separate toolkit versions Delete DTK5_MAJOR_MINOR and other derived variables that encoded DTK5-specific version segments	debian/rules
Eliminate generic build/version variables that are no longer required in the unified build flow.	Remove VERSION, PACK_VER, and BUILD_VER definitions from the rules file Remove any intermediate computations that derived or transformed these variables for packaging	debian/rules
Simplify CMake invocation by dropping explicit DTK build/version defines.	Remove -DBUILD_VERSION and -DDTK_VERSION from DTK5 and DTK6 CMake configure flags Ensure both DTK5 and DTK6 builds rely on the unified version provided by the standard build environment	debian/rules
Remove custom shared library dependency handling that depended on version-specific logic.	Delete the override_dh_makeshlibs target that injected version-specific dependency rules Rely on default debhelper/dh_makeshlibs behavior for shared library dependency generation	debian/rules

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've left some high level feedback:

• Since VERSION/PACK_VER/BUILD_VER and DTK*_VERSION variables are removed, please double-check that no other debian/* files (e.g., .install, .links, .symbols, .substvars) or external scripts still reference them or rely on their previous format.
• With -DBUILD_VERSION and -DDTK_VERSION dropped from the CMake invocation, consider whether any C++/CMake code paths that previously depended on these defines now need an alternative mechanism (e.g., using project() version or generated header) to keep embedded version information consistent.
• By removing override_dh_makeshlibs, ensure that any versioned shlibs or symbol policy that was encoded there is now handled either by default debhelper behavior or explicit shlibs/symbols files, to avoid unintentionally relaxing dependency bounds between DTK5/DTK6 libraries.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Since VERSION/PACK_VER/BUILD_VER and DTK*_VERSION variables are removed, please double-check that no other debian/* files (e.g., .install, .links, .symbols, .substvars) or external scripts still reference them or rely on their previous format.
- With -DBUILD_VERSION and -DDTK_VERSION dropped from the CMake invocation, consider whether any C++/CMake code paths that previously depended on these defines now need an alternative mechanism (e.g., using project() version or generated header) to keep embedded version information consistent.
- By removing override_dh_makeshlibs, ensure that any versioned shlibs or symbol policy that was encoded there is now handled either by default debhelper behavior or explicit shlibs/symbols files, to avoid unintentionally relaxing dependency bounds between DTK5/DTK6 libraries.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[deepin-ci-robot]

deepin pr auto review

这份 debian/rules 的 diff 内容展示了对打包构建规则的清理工作。以下是对该代码变更的详细审查，包括语法逻辑、代码质量、性能和安全性的分析。

1. 总体评价

这次修改主要是移除不再使用的变量定义和构建参数。代码逻辑上没有引入新的功能或错误，属于"减法"操作，旨在简化构建脚本。这通常是好的做法，因为减少了维护成本和潜在的出错点。

2. 详细审查意见

A. 语法与逻辑

1. 变量移除 (DTK5_VERSION, DTK6_VERSION 等)

   • 现状：删除了用于生成版本号的 sed 和 cut 管道命令，以及相关的变量定义（如 DTK5_MAJOR_MINOR, PACK_VER, BUILD_VER）。
   • 分析：这些变量原本用于生成特定的版本字符串并传递给 CMake 或 dh_makeshlibs。
   • 逻辑风险：删除这些变量意味着 CMake 配置阶段不再接收 -DBUILD_VERSION 和 -DDTK_VERSION，且 dh_makeshlibs 不再使用 -V 参数指定特定的依赖版本。
   • 潜在问题：
     • CMake 侧：必须确认项目的 CMakeLists.txt 不再依赖 BUILD_VERSION 或 DDK_VERSION 这两个外部传入的变量来定义版本号。如果 CMake 内部没有自动获取版本号的机制（例如从 git tag 或文件中读取），或者这些变量用于条件编译，删除它们会导致构建失败或生成的二进制版本号不正确。
     • 依赖管理：删除 override_dh_makeshlibs 意味着回退到 debhelper 的默认行为。默认行为通常生成 libname (= binary-version) 的依赖。原代码强制要求特定版本（例如 >= 5.6.0）。删除后，如果 ABI 发生变化但 soname 未变，可能会导致运行时加载了不兼容的旧版库，从而产生运行时错误。这是最大的逻辑风险点。

2. override_dh_makeshlibs 的删除

   • 现状：完全删除了该目标。
   • 分析：原代码针对 libdtkdeclarative5 和 libdtk6declarative 分别指定了最小依赖版本。
   • 逻辑风险：如上所述，这放宽了库的依赖限制。除非上游库已经非常稳定，或者通过符号文件（symbols 或 shlibs 文件）来严格控制 ABI 兼容性，否则这种修改可能会导致二进制兼容性问题。

B. 代码质量

1. 可读性与维护性

   • 优点：删除了复杂的 shell 管道操作（sed | cut | awk），使得 debian/rules 文件更简洁，更容易阅读。
   • 缺点：如果版本号的生成逻辑是必须的，现在被隐藏到了 CMake 或其他地方，对于打包维护者来说，逻辑变得不那么透明。

2. 冗余清理

   • 移除未使用的变量是很好的代码清理实践，符合“代码即文档”的原则。

C. 代码性能

1. 构建速度
   • 正面影响：移除了 debian/rules 执行阶段的 Shell 子进程调用（$(shell ...)）。虽然这在整个构建过程中占比极小，但在理论上是略微减少了规则解析阶段的系统开销。

D. 代码安全

1. 版本号解析的安全性
   • 移除的代码：原代码中有注释 # Fix: invalid digit "8" in octal constant...，并使用 sed 和 awk 处理版本号。
   • 分析：原代码试图修复版本号中可能存在的八进制解析问题（例如 008）。删除这部分逻辑后，如果 CMake 内部处理版本号的方式依然存在类似问题，可能会引入安全风险或构建错误。需要确保 CMake 内部的版本处理逻辑是健壮的。

3. 改进建议

1. 确认 CMake 版本处理逻辑

   • 建议：必须检查 CMakeLists.txt，确认 PROJECT 版本或 PROJECT_VERSION 是如何定义的。确保它不依赖于外部传入的 BUILD_VERSION 或 DDK_VERSION。如果依赖，建议在 CMake 内部使用 git describe 或读取 VERSION 文件来自动计算，而不是从 debian/rules 传入。

2. 关于 dh_makeshlibs 的替代方案

   • 建议：如果删除 -V 参数是有意的（例如为了简化依赖），强烈建议使用 符号文件 来管理 ABI。
   • 在 debian/ 目录下维护 libdtkdeclarative5.symbols 和 libdtk6declarative.symbols 文件。
   • dh_makeshlibs 会自动检测符号文件，如果符号发生变化，构建会报错，迫使维护者更新符号文件并更新依赖关系。这比硬编码版本号更安全、更精确。

3. 文档化变更

   • 建议：由于涉及依赖管理逻辑的重大变更（移除版本限制），建议在 debian/changelog 中明确记录这一变更，并说明理由（例如：“改用 symbols 文件管理 ABI 依赖”或“CMake 现已自动处理版本”）。

总结

这段代码变更在语法上是正确的，在性能上有微小的正面影响，但在逻辑和安全性上存在潜在风险。

• 主要风险：移除 override_dh_makeshlibs 可能会导致运行时库版本依赖过于宽松，引发 ABI 不兼容问题。
• 改进方向：确保 CMake 能够正确处理版本，并引入 symbols 文件来替代硬编码的版本依赖，以保障二进制兼容性和安全性。

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: 18202781743, asterwyx

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