fix: remove fallback to file mode in DConfig

[18202781743]

1. Removed the fallback mechanism from DBus mode to file mode in DConfig
2. DConfig now only supports DBus mode by default without falling back
   to file mode
3. This prevents applications from creating directories when calling
   interfaces during image building

The change removes the automatic fallback to FileBackend when
DBusBackend is unavailable. Previously, if DBus service wasn't
available, DConfig would fall back to file mode which could cause
directory creation during container/image building. Now it will only use
DBus mode or fail if DBus is unavailable.

Influence:

1. Test DConfig initialization when DBus service is available
2. Verify DConfig fails gracefully when DBus service is unavailable
3. Test that no directories are created during container/image building
   scenarios
4. Verify existing DBus-based configurations continue to work correctly
5. Test application behavior when DConfig cannot initialize due to
   missing DBus

fix: 移除 DConfig 中回退到文件模式的机制

1. 移除了 DConfig 中从 DBus 模式回退到文件模式的机制
2. DConfig 现在默认只支持 DBus 模式，不会回退到文件模式
3. 这可以防止在构建镜像时，应用程序调用接口去创建目录

此更改移除了当 DBusBackend 不可用时自动回退到 FileBackend 的机制。之前，
如果 DBus 服务不可用，DConfig 会回退到文件模式，这可能导致在容器/镜像构
建期间创建目录。现在它只会使用 DBus 模式，或者在 DBus 不可用时失败。

Influence:

1. 测试当 DBus 服务可用时的 DConfig 初始化
2. 验证当 DBus 服务不可用时 DConfig 优雅地失败
3. 测试在容器/镜像构建场景下不会创建目录
4. 验证现有的基于 DBus 的配置继续正常工作
5. 测试由于缺少 DBus 导致 DConfig 无法初始化时的应用程序行为

PMS: BUG-312173

[deepin-ci-robot]

deepin pr auto review

针对这段 git diff 代码审查，我的分析如下：

1. 语法逻辑

• 版权年份更新：将 SPDX-FileCopyrightText 从 2021 - 2022 更新为 2021 - 2026 是合法的，符合版权声明的常规维护逻辑。
• 回退逻辑变更：代码删除了 if (!backend) 判断块。
  • 原逻辑：尝试创建 DBusBackend，如果失败（!backend），则回退到 FileBackend。
  • 新逻辑：尝试创建 DBusBackend，无论成功与否，都不再执行回退到 FileBackend 的逻辑。
  • 潜在风险：这依赖于 DBusBackend 的构造函数在失败时是否能保证不抛出异常，或者 qCDebug 是否是唯一的错误处理方式。如果 DBusBackend 构造失败但没有抛出异常，且 backend 未被正确设置（尽管 reset 通常会生效），后续使用 backend 时可能会导致空指针解引用（Segmentation Fault）。不过，通常 reset(new ...) 即使构造函数内部有问题，只要不抛异常，指针就会被赋值。如果构造函数抛出异常，程序会终止，也走不到回退逻辑。
  • 结论：逻辑上变为"强制使用 DBus 模式"或"如果 DBus 模式不可用则报错/崩溃"，而不是"优雅降级到文件模式"。这可能是为了统一配置管理方式，但增加了系统对 DBus 服务的强依赖。

2. 代码质量

• 删除了容错机制：原代码中的回退逻辑（Fallback to DConfigFile mode）是一种良好的容错设计，允许在 DBus 服务不可用（例如服务未启动、权限问题、总线挂起）时，系统仍能通过本地文件读取配置。删除此段代码降低了系统的健壮性。
• 日志缺失：删除了 qCDebug(cfLog, "Can't use DBus config service, fallback to DConfigFile mode"); 这行日志。这会导致当 DBus 模式初始化失败时，开发者或运维人员无法直接从日志中看到系统已经尝试回退（或者现在是不回退了）的信息，增加了排查问题的难度。

3. 代码性能

• 性能影响极小：从性能角度看，删除一段条件判断和日志输出，对运行时性能的提升微乎其微，几乎可以忽略不计。这不是性能优化的有效手段。

4. 代码安全

• 拒绝服务/稳定性风险：如果 DBusBackend 的初始化依赖于外部 DBus 服务，而该服务由于某种原因（被攻击、崩溃、配置错误）不可用，原代码可以保证系统降级运行，维持基本功能。新代码可能导致整个配置模块失效，进而导致依赖此配置的应用程序崩溃或无法启动，构成了潜在的拒绝服务风险或稳定性风险。
• 依赖单一故障点：移除文件回退机制意味着 DBus 成为了单一故障点（SPOF）。

改进建议

1. 确认意图：首先需要确认删除回退逻辑是有意的架构变更（例如：强制要求所有环境必须支持 DBus 配置服务），还是误操作。

   • 如果是强制要求：建议在 DBusBackend 构造失败时抛出明确的异常或致命错误日志，而不是静默失败或仅依靠构造函数的行为。这样可以快速定位环境配置问题。
   • 如果是误操作或需要兼容性：建议恢复这段代码。

2. 增强错误处理（如果必须删除回退逻辑）：
   如果决定不再支持文件回退，建议在 new DBusBackend(this) 之后增加检查逻辑，或者确保 DBusBackend 构造函数在失败时抛出异常，并在外层捕获并记录严重错误。

   // 示例：如果必须强制使用 DBus
   try {
       backend.reset(new DBusBackend(this));
       // 假设 DBusBackend 有一个 isValid() 方法或者构造后可能处于无效状态
       if (!backend || !backend->isValid()) {
           qCCritical(cfLog, "Failed to initialize DBusBackend and file fallback is disabled.");
           // 根据业务需求，决定是抛出异常、终止程序还是返回空指针
           throw std::runtime_error("DBusBackend initialization failed");
       }
   } catch (const std::exception& e) {
       qCCritical(cfLog, "Exception while creating DBusBackend: %s", e.what());
       // 处理异常...
   }

3. 保留日志：
   即使删除了回退逻辑，保留相关的 Debug 或 Warning 日志对于排查 DBus 连接问题依然非常有帮助。

总结：这段修改主要涉及系统架构的健壮性和容错性。除非有明确的架构升级需求（如废弃文件配置），否则建议恢复被删除的代码块，以维持系统在 DBus 不可用时的降级服务能力。

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

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

[18202781743]

/forcemerge

[deepin-bot]

This pr force merged! (status: blocked)