问题标签 [software-packaging]

我们如何创建一个软件包，以便在解压我们的软件 tar 球后，用户可以执行典型的步骤？

有没有办法提供 Debian 打包控制文件的本地化版本（例如变更日志、控制和版权）？

我使用 Debhelper 创建 Debian 软件包。为了部署文件和目录，我使用debian/installanddebian/dirs文件。

现在我希望我的包将默认用户配置文件部署到 $HOME/.mypackagerc（就像 .bashrc 和朋友一样）。

Debhelper 是否提供了一种方法来做到这一点，或者我应该只是：

• 在 postinst 脚本中执行
• 甚至在我的程序中执行此操作，在第一次执行时

是否有任何免费工具可以用来将我的战争（Java Web 应用程序）和 tomcat 打包为 exe

在我担任 SysAdmin 期间，我遇到过不提供 rpm 包来安装在基于 redhat 的发行版上的应用程序 - 仅提供源 tarball。源 tarball 不提供可以简化 rpm 包创建过程的规范文件。相反，源 tarball 仅提供 bash/ksh/ 脚本，必须以 root 身份执行才能在系统上安装应用程序。

我试图创建一个 rpm 包，它基本上运行安装脚本来执行安装脚本。我还尝试通过尝试以非 root 用户身份 rpmbuild 软件包并尽我所能修改安装脚本以确保脚本的安装目录引用 rpm 环境/宏来做正确的事情。但是对于一个几百行长的复杂安装脚本，它还调用了其他脚本......好吧，我注定要失败。

有没有更好的方法来打包这种 .spec-less 源 tarball？更好的解决方案是：

1. 在应用程序安装之前以某种方式拍摄系统快照
2. 使用提供的安装脚本安装源 tarball
3. 安装后对系统进行快照，并确定安装所做的更改/添加
4. 将更改/添加列表放入规范文件中，并以这种方式创建 rpm 包？

对此问题的任何有用/相关/指导性/有趣/深刻的输入和建议将不胜感激。

先感谢您

我手头有一个大型项目（master），它分为几个组件（liba、b、c、d）以简化构建和维护。在构建整个包时，必须按顺序构建所有子组件，其中一些包相互依赖。

更明确地说，liba 是 b、c 和 d 的先决条件，并且 liba 的存在由配置脚本检查。在单独构建 b 发行版时，此检查对于提供用户友好的错误消息绝对是必要的。但是，在构建主包及其所有子包时，liba 被构建为子目标。因此，当在 master 套件上运行 configure 时，liba 尚未安装，并且 b 中的 liba 检查失败。

我可以通过将 --with-liba=internal 或类似标志传递给 b 的配置脚本来纠正此问题；但是，我还没有找到任何关于这种自动配置标志传递的文档。目前，我在 master 中有一个很长很长的自定义 Makefile，它与子目录的 autoconf/automake 一样，但重新排序依赖关系，而不是 (configure liba) => (configure b) => (build liba) => (build b)，顺序是 (configure liba) => (build liba) => (install liba) => (configure b) => (build b)。

知道如何使用标准的 autoconf/automake 子目录来重构它吗？

我正计划编写一些 Java 应用程序并计划以免费和商业版本分发。基本上我的想法是从企业用户那里获得一些钱。我想提供扩展 API，其他用户可以编写一些 jar 并包含在产品中。

请帮我解决以下问题。

1）如果我作为 JAR 分发，即使我进行了混淆，任何人都可以看到我的代码。我认为有一些付费的去混淆器..使 exe 或 JNI 成为一个选项，但这不是一个有效的解决方案。微软产品没有这个问题。有什么建议吗？

2）如果我做开源，我不会获得太多收益，因为除非像 IBM websphere 或 RAD 这样的巨大产品，企业通常不会寻求支持。有什么可以避免这种情况的输入吗？

I am finishing a Java library that I want to make available to third parties. In addition to its core functionality, I am providing some classes that ease the usage of my library when used as part of an Eclipse plugin. Then, I have some dependencies in my library to certain OSGi/Eclipse classes (e.g., org.osgi.framework.Bundle, org.eclipse.core.runtime.FileLocator, org.eclipse.jdt.core.dom.CompilationUnit, among others).

So my questions is: What is the correct/convenient way to package this library for third parties usage?. Should I include all the Eclipse jars that contain the required dependencies ?. Intuitively, I think this is not a good solution given that the user obviously could have a different Eclipse version than the one I have, and this could lead to class loading conflicts. The solution of just not providing the Eclipse jars - and asking the user to find the ones he/she likes - does not really convince me neither.

I do not have lots of experience with Maven, but as far as I understand I can create a POM file that the user can use for downloading the last version of my project and its dependencies. But again: in that case I also have to decide if I should include or not the Eclipse jars in the download, considering the reasons I wrote above.

Thanks for sharing your experience on this regard.

我们是一家蟒蛇店。我们内部开发了不同的 python 包，并将部署到客户的环境（机器）上。

这就是我们的开发和发布周期发生的方式。

一旦开发人员完成了包的“测试”，就会准备好包的分发（egg 文件）并将其推送到中央归档位置。当我们想将我们的软件部署给客户时，相同的发行版（egg 文件）将被下载并安装在他们的环境中。

假设“测试”发生在多个操作系统上（检查 API 跨平台的兼容性），准备发行版并将其推送到中央存档位置的最佳实践是什么。

是否最好在归档服务器上有操作系统特定的鸡蛋（如 samplepkg-1.0.0.win32.egg 和 samplepkg-1.0.0.linux.egg ？不确定如何使用 setuptools 以这种方式准备它们。）或者只有一个鸡蛋，因为 API 在不同平台上保持不变？社区遵循的任何其他做法？

独立 Java SE（基于命令行）应用程序的标准项目目录结构是什么？

src文件夹将包含我.java在正确组织的包中的所有文件。除此之外，我还有bin包含我的文件的.class文件夹。

我的项目中有属性文件和 XML 配置文件。我应该将它们放在哪个目录中？我应该创建一个名为com.myproject.config并将所有.xml配置文件放在其中的包吗？

我希望将依赖的 jar 与我的最终包一起打包。那么我应该创建一个文件夹（比如名称lib）来保存所有这些.jar文件吗？