Debian 软件包控制文件问题
我正在尝试为 Java 应用程序创建 Debian 包。
在我的包中，有一个可执行的 .jar 文件、一个将运行该 jar 文件的脚本和一个用于 fmod 的 .so 文件。 我已阅读本教程。
在控制文件中，有一个“取决于”字段，它基本上描述了安装我的应用程序所需安装的软件包。我的问题是，如何找到我的应用程序所需的软件包？我按照教程中的说明操作了其中一个 .so 文件，并得到了以下信息：
$ dpkg -S libfmodex64-4.28.09.so
dpkg: *libfmodex64-4.28.09.so* not found.
此外，我的应用程序需要安装 Java 1.5 才能运行。如何在我的 Debian 软件包中指定它？
I am trying to create a Debian package for a Java application.
In my package there is a .jar file which is executable, a script which will run this jar file and a .so file for fmod.
I've read this tutorial.
In the control file there is a 'Depends' field which basically describes the packages that need to be installed in order to install my application. My question is, how do I find which packages are required for my application? I followed the instructions in the tutorial for one of the .so files, and got this:
$ dpkg -S libfmodex64-4.28.09.so
dpkg: *libfmodex64-4.28.09.so* not found.
Also, my application requires Java 1.5 to be installed in order for it to run. How do I specify this in my debian package?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我强烈建议您在 Debian 打包基础设施中从源代码构建您的软件包。如果您在 CDBS 中使用 Ant 类，那么一切都会自动处理。
如果您确实坚持只组装二进制
.deb，则 equivs 就足够了比您的文档中描述的方法更少黑客。I strongly recommend building your package from source within the Debian packaging infrastructure. Everything will be pretty much automatically taken care of if you use the Ant class in CDBS.
If you do insist on assembling a binary
.debonly, equivs is much less hackish than the method described by your document.您需要获取库的规范名称：
apt-cache search libname请注意记下包末尾的术语。您不想在控制文件中指定特定版本，而只需指定适合您的应用程序的库的最早版本。
然后，您可以使用canonical_libname>=major.minor，它让系统决定您是否拥有（或可以更新到）可以支持您的应用程序的库版本。如果您及时完成此操作，即指定当前库的完整版本，您将来将会崩溃。
例如，如果您指定
libfoo-1.2.34和 Debian 未来版本的libfoo-2.3.45，您的软件包将不会安装，因为它认为您有一个libfoo 的版本不兼容。You'll want to get the canonical name for your library:
apt-cache search libnameTake care to note the nomenclature at the end of the package. You don't want to specify a specific version in the control file, just the earliest version of the library that is suitable for your application.
You would then use
canonical_libname >= major.minor, which lets the system decide if you have (or can update to) the version of the library that can support your application. If you carve this in time, i.e. specifying the full version of your current library, you'll break in the future.For instance, if you specify
libfoo-1.2.34and future versions of Debian shiplibfoo-2.3.45, your package won't install, because it thinks you have an incompatible version of libfoo.