依赖于 libcurl.so、libsqlite3.so、libcrypto.so 和 libpthread.so 的程序的 Debian 控制文件依赖项

Debian control file dependencies for a program which depends on libcurl.so, libsqlite3.so, libcrypto.so and libpthread.so

我有一个程序依赖于 libcurl.so、libsqlite3.so、libcrypto.so 和 libpthread.so

Package: myscript
Version: 0.1
Section: utils
Priority: optional
Architecture: all
Essential: no
Depends: curl | libcurl3, sqlite3 | libsqlite3-0, libcrypto++9 | libk5crypto3
Maintainer: Your Name
Description: Sample Program

我的问题是， 1. 我想在控制 file.My 机器（linuxmint-17）中添加 libpthread 依赖项有一个名为 libthread.so.10 的文件。但是当我执行 dpkg --get-selections 时，我没有得到任何包含 pthread 的包。这是 linuxmint(17) 的全新安装，我没有手动安装任何软件包。 2.How 我会确保这会起作用吗，让我们说如果 libcurl4 或 libcrypto++99 进来 future.Am 我遵循正确的方法还是我遗漏了什么。

首先，请阅读Debian documentation about control file。

您需要在 debian/control 文件中指定的是 Source 部分中的 -dev 包。在 Package 部分中，当您在大多数情况下描述生成的二进制包时，行 Depends: ${shlibs:Depends}, ${misc:Depends} 就足够了。确保 dh_shlibdeps 是 运行 debian/rules。据我所知，dh_make 为您介绍了这些 - 查看 dh_make 文档。

了解具有 .so 和 .so.some.numbers.here 扩展名的库之间的区别。提供了很好的解释 here。

所以，在debian/control中你应该有一个源码包部分：

来源：包名 Build-Depends: packages-dev, other-packages-needed-for-build [其他领域]

以及从该来源构建的二进制包的一个或多个部分：

包：包名 取决于：${shlibs:Depends}, ${misc:Depends} [其他领域]

如何确定要放入 Build-Depends 中的包？如果您需要选项 -lfoo 才能成功 link 您的软件，这意味着您需要有一个文件 libfoo.so 可用。 -pthread 选项隐式添加了 -lpthread 选项。因此，对于 PCRE，您需要 libpcre.so 文件，对于 pthreads - libpthread.so。当您建立名称时，运行 dpkg -S 将所有这些文件名作为参数。您可能希望 grep 结果只获得 .so 文件，而不是 .so.something.

arturcz@szczaw:~$ dpkg -S libpcre.so libpthread.so | grep '\.so$'
libpcre3-dev:amd64: /usr/lib/x86_64-linux-gnu/libpcre.so
libc6-dev:amd64: /usr/lib/x86_64-linux-gnu/libpthread.so

因此，您要作为 Build-Dependencies 放置的包名称是：libc6-dev 和 libpcre3-dev。然而，另一个规则是在 Debian 中使用。有些包被认为是 build essential 并且您不需要将它们放入 Build-Dependencies 中。 libc6-dev 就是其中之一。如果您正确地 debianized 您的软件，${shlibs:Depends}, ${misc:Depends} 将被适当的内容替换。

How will I ensure that this will work, let us say if libcurl4 or libcrypto++99 comes in future.Am I following the correct method or am I missing something.

你不会的。如果库的 SONAME 中的主要编号发生变化，则意味着 API 或两个库的行为都发生了变化。您需要使用新库再次编译您的软件，对代码进行必要的更改，然后对其进行测试并修复问题。

进一步推荐阅读：