第一阶段:

1.二进制库
例如：
调用xx库，共性提 ldd
dpkg -L bash
ldd /bin/rbash
dpkg -S 库来源

2.dbus
快速入门博客：  https://blog.csdn.net/Dontla/article/details/122530765

最常见的基于dbus的程序也符合C/S结构。比如开发两个程序A和B，其中A是客户端，B是服务端。假设A要调用B的一个函数func，那么实际的消息流动方向是：A告诉dbus-daemon请求要调用B的func函数，然后dbus-daemon去调用B的func函数，如果func有返回值的话，B会把返回值告诉dbus-daemon，然后dbus- daemon再把返回值告诉A。如果B进程还没有启动，则dbus-daemon会自动的先把B进程启动起来。
当A通过dbus-daemon请求调用b的函数，就说明A是依赖B的。


3.依赖符号判断
除同源包外，依赖版本不能用=写死
有< 号时，需要给出waring，进行人工自检
有> 号时，需要判断版本号是否包含小版本号release(version-release)，如果有置failed

代码逻辑为：
（1）先apt show 获取所有依赖，当依赖中有| 时，将两边分别看成独立的依赖
（2）对依赖进行分析：当符号为有且仅有=时，使用 apt-cache show 指令获取包和依赖包中的SOURERS 字段，判断是否为同一个源码包，是就置为OK，否就置为ERROR
（3）当符号有< 时，置为Warning
（4）当符号为> 时，判断依赖包版本号是否包含release，包含就置为 Failed 
（5）所有信息都打印到output.txt 中，警告和错误信息额外打印到sign_judgment.txt 中


4.depends自动加依赖？
说明：
在`debian/control`文件中，`Depends`字段通常用于声明软件包的直接依赖关系。然而，当软件包依赖于某些共享库或其他资源时，这些依赖可能需要通过特殊的变量来自动生成，以确保软件包能够正确地链接到所需的库。

`${shlibs:Depends}`和`${misc:Depends}`是两个预定义的变量，它们在`debian/control`文件中用于处理共享库依赖和一些其他类型的依赖。

1. `${shlibs:Depends}`：这个变量用于自动检测并添加对共享库的依赖。它告诉dpkg或apt等软件包管理系统，当前软件包依赖于哪些共享库。这些共享库通常是软件包运行时所需的动态链接库（.so文件）。

2. `${misc:Depends}`：这个变量用于添加一些其他类型的依赖，例如配置文件、设备驱动或者其他非共享库的资源。这些依赖可能不是直接的可执行文件或库，但对于软件包的正常运作是必需的。

${shlibs:Depends}
用途：此变量用于自动管理二进制包对共享库的依赖。
如何工作：dh_shlibdeps工具会扫描软件包中的所有ELF可执行文件和共享库，自动计算它们对其他库的依赖，并将这些依赖记录到DEBIAN/control文件中。这些记录会替换${shlibs:Depends}变量。
${perl:Depends}
用途：此变量用于管理Perl脚本或模块的依赖。
如何工作：dh_perl工具会检测软件包中的Perl脚本或模块，自动确定它们所需的Perl版本或API，并将这些依赖记录到DEBIAN/control文件中。这些记录会替换${perl:Depends}变量。
${misc:Depends}
用途：此变量用于管理由其他debhelper工具自动添加的其他依赖。
如何工作：在软件包构建过程中，各种debhelper命令可能会添加对其他软件包的依赖（例如，需要某些特定的工具或库）。dh_gencontrol等工具会收集这些依赖并记录到DEBIAN/control文件中，替换${misc:Depends}变量。



第二阶段：
5.符号表？ （2403-update1 Qt-base 以供参考）

6.包里面的脚本（脚本指令由哪些包提供，需要检测）

7.不能直接使用软件，而是引用库/dbus服务，使用了哪些东西？

8.上层不应该直接使用X11 作为依赖，应该使用Qt等

9.纯软件不能有硬件相关的库



开发过程：
1.二进制功能调试过程中发现很多包有使用到linux-vdso.so.1 这个库，但是dpkg -S 是没有匹配项目的，查询资料发现linux-vdso.so.1 是一个特殊的虚拟动态共享对象，它并不是一个真实的文件，而是由 Linux 内核在程序运行时动态生成的一个映射。这个文件不是从软件包中提供的，而是由操作系统内核提供的。
所以为了排除这种无效信息，设立了一个库白名单.xlsx 文件，把linux-vdso.so.1 写入了白名单中，之后在收集结果的时候就可以先匹配白名单

需要装两个python组件

pip install pandas openpyxl

2.二进制功能调试过程发现一些包使用apt-cache depends 打印依赖信息有特殊情况
例如：apt-cache depends apt-p2p
apt-p2p
  依赖: <python2:any>
    python2
  依赖: <python2:any>
    python2
  依赖: adduser
  依赖: <python>
    python-is-python2
  依赖: python3
  依赖: python-apt
  依赖: python-debian
  依赖: python-twisted-web2
  冲突: apt-p2p-server

输出中的 <...> 形式表示软件包依赖的是一个虚拟包或替代包。

虚拟包是一种抽象的包名，代表了一组可以提供相同功能的软件包。比如说输出中的 <python2:any>，这表示 apt-p2p 需要任何提供 python2 功能的软件包。在这种情况下，python2 是一个虚拟包，可以由系统中安装的任何版本的 Python 2 实现（如 python2.7）。这种依赖关系允许软件包开发者指定一个广泛的需求，而不用特定到某个具体的软件包版本。
类似地，<python> 指代另一个虚拟包，可能被任何实现了 Python 运行时的包满足，比如 python-is-python2，表示该软件包需要任何版本的 Python，且在这种情况下，它被 python-is-python2 满足，所以系统内该依赖指的是python-is-python2 这个包。

所以需要添加判断，如果依赖：这类关键词后面是< ，就获取下一行的包名



3.关于${shlibs:Depends}，${perl:Depends}，${misc:Depends} 自动依赖
首先，自动依赖的字段都写在源码目录debian/control 中，想要查看相关信息首先需要有源码包（应该需求的使用场景是定值版本中，正常的版本里面应该不会有源码包存在，这个需求项是否可行？或者调到第二阶段）
如果想手动获取自动依赖的具体值，需要以下步骤：
（1）安装debhelper，因为dh_shlibdeps 等指令都是由该包提供
（2）安装构建依赖然后对软件包进行构建（dpkg-buildpackage指令），查看是否生成elf执行文件和共享库
（3）在debian 目录下运行dh_shlibdeps，它会在这个位置查找debian/tmp/或debian/<package>/等目录以分析可执行文件和库，计算它们的依赖关系，并更新相应的debian/control文件中的依赖字段。


4.关于D-Bus
使用D-Bus判断软件直接依赖关系的具体方法：
（1）使用dbus-monitor 指令查看总线上的所有消息
dbus-monitor --system (系统总线)
dbus-monitor --session （消息总线）
（2）分析dbus-monitor 捕获的消息，可以看出来哪个程序A请求调用了哪个程序B，消息内容一般会包括调用的接口和方法
（3）通过记录和分析这些调用，能识别出哪些服务依赖于某个服务，比如A频繁调用了B的服务，可以认为A依赖于B

因为D-Bus的依赖分析基于捕获运行时的消息，只有当应用程序实际运行并通过D-Bus发送请求时，这些依赖关系才会被捕捉到。
所以D-Bus 方法主要适用于实时分析正在运行的应用程序之间的交互，而不适合静态地分析系统内安装的所有软件包的依赖关系。
