Skip to content

Conversation

@18202781743
Copy link
Contributor

  1. Removed DTK5_VERSION and DTK6_VERSION variable definitions that were
    derived from DEB_VERSION_UPSTREAM
  2. Removed DTK5_MAJOR_MINOR variable calculation
  3. Removed override_dh_makeshlibs target that set different version
    dependencies for DTK5 and DTK6
  4. Simplified build system to use consistent versioning between DTK5
    and DTK6

The changes were made as part of DTK unified build transformation
where DTK5 and DTK6 now share the same version numbers. Previously,
the build system automatically generated different version numbers for
DTK5 and DTK6 based on the upstream version (e.g., 5.6.8 would become
DTK5_VERSION=5.6.8 and DTK6_VERSION=6.6.8). Now that both DTK5 and
DTK6 use the same version scheme, this differentiation is no longer
needed. The dh_makeshlibs override that set different minimum version
dependencies for DTK5 and DTK6 libraries has also been removed since
they now share versioning.

Influence:

  1. Verify that DTK5 and DTK6 packages are built with identical version
    numbers
  2. Test that library dependencies are correctly resolved without version
    conflicts
  3. Ensure backward compatibility with existing installations
  4. Validate that both DTK5 and DTK6 components can be installed
    simultaneously
  5. Test package upgrades from previous versions with different
    versioning schemes

chore: 移除构建规则中dtk5/6版本差异化处理

  1. 删除了从DEB_VERSION_UPSTREAM派生的DTK5_VERSION和DTK6_VERSION变量定义
  2. 删除了DTK5_MAJOR_MINOR变量计算
  3. 删除了为DTK5和DTK6设置不同版本依赖的override_dh_makeshlibs目标
  4. 简化了构建系统,使DTK5和DTK6使用一致的版本控制

这些更改是DTK统一构建改造的一部分,现在DTK5和DTK6使用相同的版本号。之
前,构建系统会根据上游版本自动为DTK5和DTK6生成不同的版本号(例如,5.6.8
会变成DTK5_VERSION=5.6.8和DTK6_VERSION=6.6.8)。现在DTK5和DTK6使用相同的
版本方案,不再需要这种差异化处理。同时移除了为DTK5和DTK6库设置不同最低版
本依赖的dh_makeshlibs覆盖,因为它们现在共享版本控制。

Influence:

  1. 验证DTK5和DTK6包是否使用相同的版本号构建
  2. 测试库依赖关系是否能正确解析,没有版本冲突
  3. 确保与现有安装的向后兼容性
  4. 验证DTK5和DTK6组件是否可以同时安装
  5. 测试从先前使用不同版本方案的版本进行包升级

@deepin-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

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

Details Needs approval from an approver in each of these files:

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

Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR simplifies the Debian build system by removing the version differentiation logic between DTK5 and DTK6 packages, aligning with the unified versioning approach where both DTK5 and DTK6 now share the same version numbers (as evidenced by the recent transition to 6.7.31).

Changes:

  • Removed automatic version transformation logic (DTK5_VERSION and DTK6_VERSION variable definitions)
  • Removed DTK5_MAJOR_MINOR variable calculation
  • Removed override_dh_makeshlibs target that set different minimum version dependencies for DTK5 and DTK6 libraries

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

1. Removed DTK5_VERSION and DTK6_VERSION variable definitions that were
derived from DEB_VERSION_UPSTREAM
2. Removed DTK5_MAJOR_MINOR variable calculation
3. Removed override_dh_makeshlibs target that set different version
dependencies for DTK5 and DTK6
4. Simplified build system to use consistent versioning between DTK5
and DTK6

The changes were made as part of DTK unified build transformation
where DTK5 and DTK6 now share the same version numbers. Previously,
the build system automatically generated different version numbers for
DTK5 and DTK6 based on the upstream version (e.g., 5.6.8 would become
DTK5_VERSION=5.6.8 and DTK6_VERSION=6.6.8). Now that both DTK5 and
DTK6 use the same version scheme, this differentiation is no longer
needed. The dh_makeshlibs override that set different minimum version
dependencies for DTK5 and DTK6 libraries has also been removed since
they now share versioning.

Influence:
1. Verify that DTK5 and DTK6 packages are built with identical version
numbers
2. Test that library dependencies are correctly resolved without version
conflicts
3. Ensure backward compatibility with existing installations
4. Validate that both DTK5 and DTK6 components can be installed
simultaneously
5. Test package upgrades from previous versions with different
versioning schemes

chore: 移除构建规则中dtk5/6版本差异化处理

1. 删除了从DEB_VERSION_UPSTREAM派生的DTK5_VERSION和DTK6_VERSION变量定义
2. 删除了DTK5_MAJOR_MINOR变量计算
3. 删除了为DTK5和DTK6设置不同版本依赖的override_dh_makeshlibs目标
4. 简化了构建系统,使DTK5和DTK6使用一致的版本控制

这些更改是DTK统一构建改造的一部分,现在DTK5和DTK6使用相同的版本号。之
前,构建系统会根据上游版本自动为DTK5和DTK6生成不同的版本号(例如,5.6.8
会变成DTK5_VERSION=5.6.8和DTK6_VERSION=6.6.8)。现在DTK5和DTK6使用相同的
版本方案,不再需要这种差异化处理。同时移除了为DTK5和DTK6库设置不同最低版
本依赖的dh_makeshlibs覆盖,因为它们现在共享版本控制。

Influence:
1. 验证DTK5和DTK6包是否使用相同的版本号构建
2. 测试库依赖关系是否能正确解析,没有版本冲突
3. 确保与现有安装的向后兼容性
4. 验证DTK5和DTK6组件是否可以同时安装
5. 测试从先前使用不同版本方案的版本进行包升级
@deepin-ci-robot
Copy link
Contributor

deepin pr auto review

这段代码是 Debian 软件包构建规则文件 debian/rules 的一个差异补丁。主要变化是删除了与 DTK (Deepin Tool Kit) 版本号处理相关的变量定义以及 dh_makeshlibs 的自定义覆盖规则。

以下是对这些变更的详细审查意见,涵盖语法逻辑、代码质量、代码性能和代码安全四个方面:

1. 语法逻辑

  • 变更分析
    • 删除变量定义:删除了 DTK5_VERSIONDTK6_VERSIONDTK5_MAJOR_MINOR 的计算逻辑。这些逻辑依赖 DEB_VERSION_UPSTREAM 并使用 sed 进行字符串替换。
    • 删除 override_dh_makeshlibs:删除了自定义的 dh_makeshlibs 目标。原目标中使用了 -V 参数来指定依赖关系(如 libdtkcore5 (>= x.y)),这通常用于确保二进制兼容性。
  • 潜在风险
    • 依赖管理逻辑缺失:删除 override_dh_makeshlibs 后,dh_makeshlibs 将使用默认行为。默认情况下,它生成的 shlibs 文件通常依赖当前包的精确版本(例如 libdtkcore5 (= 5.6.8))。
    • 兼容性影响:原代码强制要求依赖库的主版本号(如 >= 5.6),这允许小版本更新。删除后,如果下游包依赖于旧版本的行为,可能会因为严格的版本锁定(=)导致无法平滑升级,或者如果默认行为不符合预期,可能导致运行时库找不到。
    • 逻辑一致性:代码中仍然保留了 BUILD_DTK5BUILD_DTK6 的控制逻辑,说明项目依然支持双版本构建。删除版本号变量意味着后续构建步骤可能不再需要这些具体的版本号字符串(例如 CMake 配置中可能不再需要传入 DTK5_VERSION)。如果 CMake 或其他脚本内部仍依赖这些环境变量,构建将会失败。

2. 代码质量

  • 简化与可维护性
    • 正面:删除复杂的 Shell 命令链(如 sedawk 的组合)提高了 rules 文件的可读性。原来的正则表达式 sed -E 's/^[0-9]+(\.|[^0-9]|$$)/5\1/' 较为晦涩,维护成本高。
    • 负面:如果删除这些变量是为了"清理"代码,但并未确认这些变量是否在其他地方(如 debian/controldebian/*.install 或 CMakeLists.txt)被引用,这属于降低代码健壮性的改动。
  • Shell 脚本规范
    • 原代码中使用了 $(shell ...),这是 Makefile 的标准写法,语法上没有问题。删除后减少了 Make 执行时的 Shell 子进程生成,略微提升解析效率。

3. 代码性能

  • 构建性能
    • 正面:删除了 override_dh_makeshlibs。在原代码中,dh_makeshlibs 被拆分为针对不同包的多次调用。虽然删除它本身不会显著改变性能(因为 dh_makeshlibs 仍然会被默认规则调用),但减少了 debian/rules 文件本身的逻辑分支判断,使 Make 解析稍微快一点。
    • 正面:移除了 sedawk 等外部命令的调用,减少了 dpkg-buildpackage 初始化阶段的系统调用开销。

4. 代码安全

  • 注入风险
    • 原代码中的 $(shell echo $(DEB_VERSION_UPSTREAM) | ...) 存在潜在的 Shell 注入风险,如果 DEB_VERSION_UPSTREAM 包含恶意字符(虽然版本号通常受 Debian 打包工具限制,不太可能包含恶意字符,但理论上存在风险)。删除这些行消除了这一潜在的(尽管极小)风险点。
  • 版本欺骗
    • 删除了手动计算 DTK5_VERSION 的逻辑,转而依赖上游版本号 DEB_VERSION_UPSTREAM。这减少了版本号计算错误导致的安全漏洞(例如错误地将补丁版本号当作主版本号处理)。

改进建议

  1. 确认依赖关系

    • 最关键的一点是:请确认删除 override_dh_makeshlibs 是有意为之
    • 如果目的是让依赖关系由 debian/control 中的 shlibs 文件或符号文件控制,那么这是正确的。
    • 如果目的是自动生成依赖,请确保生成的依赖关系(通常是 package-name (= binary-version))符合项目的发布策略。如果需要支持向后兼容(ABI 兼容),通常需要显式指定最低版本(如 -V "libdtkcore5 (>= 5.6)")。
    • 建议:如果需要自定义依赖版本,建议使用 debian/*.symbols 文件(符号文件)来管理 ABI 版本,这是比在 rules 文件中硬编码 -V 参数更现代、更推荐的做法。
  2. 清理未使用的变量

    • 检查 BUILD_VER 的计算逻辑。它使用了复杂的 awksed 链式调用:
      BUILD_VER := $(shell echo $(DEB_VERSION_UPSTREAM) | awk -F'[+_~-]' '{print $$1}' | awk -F'.' '{print $$4}' | sed 's/[^0-9]//g' | awk '{print int($$1)}')
    • 这段代码依然保留,看起来非常脆弱且难以维护。建议检查是否可以简化,或者确认它是否真的被使用。
  3. 代码风格

    • debian/rules 文件现在的改动倾向于更简洁。建议继续保持这种风格,避免在 Makefile 中编写复杂的 Shell 逻辑。如果必须进行复杂的字符串处理,建议将其移至一个辅助的 Shell 脚本中,并在 rules 中调用该脚本。

总结

这段 diff 的主要意图是简化构建逻辑,移除了对 DTK 特定版本号的硬编码处理。这在代码质量和性能上是正向的改进。

核心风险在于删除 override_dh_makeshlibs 可能会改变生成的二进制包的依赖关系。请务必确保:

  1. 项目不再需要手动指定 libdtkcore 的最低依赖版本。
  2. 或者,项目已经转用 debian/*.symbols 文件来更精细地管理符号版本和依赖关系。

如果以上两点确认无误,那么这是一个好的重构;否则,可能会导致运行时依赖错误。

@18202781743 18202781743 merged commit cd0f07f into linuxdeepin:master Jan 21, 2026
18 of 19 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants