问题标签 [debian-packaging]

我的要求是在安装 apt install my_test_100 然后它应该过时 test_100 即它应该删除旧的 test_100 并安装新的 my_test_100 包

在 rpm 中，我们将此标记过时：test_100

所以在 centos7 上，当我们执行 yum install my_test_100 时，它会移除旧的包 test_100 并安装新的 my_test_100 包

任何 !dea / 或 deb 包的代码？

我正在尝试使用 Github Actions 将我的 Python 项目打包为 .deb 推送。我正在使用 dh-virtualenv。我已经在本地对其进行了测试，它工作正常，但我在操作工作流程方面遇到了麻烦。据我所知，问题在于 Action 运行器没有读取与 .gitignore 文件匹配的一些源目录和构建目录。我收到以下错误：

该命令能够在 repo 中找到与 .gitignore 不匹配的所有其他文件。此外，当在我的本地机器上运行相同的进程时，所有源目录都被创建并找到并且没有错误。

我的 Actions 工作流 yml 文件如下所示：

如您所见，我尝试在签出代码后删除 .gitignore 文件，但这不起作用。我不想真正从存储库中删除 .gitignore 文件，因为我不希望所有构建工件都成为源代码的一部分。我在这里缺少什么吗？有没有人成功做到这一点？

有一个简单的控制文件：

另外，我有一个 Map<> 包含： package : version

我需要修改此文件的Build-Depends属性（通过 groovy/Jenkins/shell）并替换每个完全不包含版本限制的构建依赖项（例如 pkg-config）以包含特定版本：（= 1.0）

版本应取自地图

修改后的文件应该是这样的：

归根结底，需要一些方法来遍历 Build-Depends 检查是否包含版本限制，如果没有，则将版本从 Map

任何想法？我可以使用文本处理方法来做到这一点，但我会寻找更官方的方式来处理 Debian 的控制文件修改

我正在尝试dpkg-buildpackage在 Xenial 容器上运行，但我找不到从哪里获取debhelper-compat包。

我已尝试按照此评论的建议进行操作，但未debhelper提供debhelper-compat.

我发现如果我从中删除debhelper-compat，debian/control例如

10并在里面放一个数字debian/compat，然后我运行dpkg-buildpackage成功。

有没有办法简单地下载依赖项？不确定debhelper-compat软件包是否是新的，但它存在于 Ubuntu18.04 apt search 中。

我有一个自定义 Python 包/脚本，我正在尝试为其构建一个 Debian 包。它在 Debian 11 系统上构建和安装良好。现在我还想将它打包到一台装有 Ubuntu 18.04 的机器上。

该程序使用从 Python 3.8 开始支持的注释（使用 from __future__ import ...），因此我至少需要 3.8。在 Ubuntu 18.04 上，标准 python3 是 3.6.7，但包 python3.8 提供 3.8。然而，尽管我尽了最大努力，我还是不知道如何将非默认版本指定为唯一依赖项，即告诉 debuilder 等仅依赖于 python3.8 而不是 python3（默认）。

这有可能吗？如果有，怎么办？运行这个程序所需的所有包都在标准存储库中，所以我认为应该可以正确定义依赖关系 - 不知何故。我对包装比较陌生，非常感谢任何指针（尽管我已经阅读了易于查找的文档等......）

到目前为止我尝试过的事情（仅显示 /debian/control 的相关部分）：

取决于 python3 和 python3.8，没有明确指定 X-Python 版本：

/debian/控制

-> 构建，但不会配置（在包安装期间），因为它使用的是 python 3.6.x

取决于 python3 和 python3.8，并指定 X-Python 版本

-> 构建，但也不会配置（在包安装期间）

仅依赖python3.8，并指定X-Python版本

-> 构建期间的错误（缺少依赖项）

-> 和包安装过程中的错误

我计划为 x86-64 架构构建不同版本的密集数值程序。方便的是，在 2020 年，定义了 4 个级别的 x86-64 微架构，可以通过“-march”标志传递给编译器。因此，对于 GCC 11（对于 Clang 12 也是如此），我应该能够通过指定使用 AVX、AVX2 和 LZCNT 指令

并将其扩展为 AVX512

如果我用它创建一个 Debian 包，它可能被称为

但是，实际上有两个版本。在机器上运行该x86-64-v4版本x86-64-v3会导致 SIGILL（非法指令）。有人向我建议：

其中 x3 代表 x86-64-v3，x4 代表 x86-64-v4。但我认为这违反了 Debian 'arch' 说明符规则。将其添加到包名称的版本部分会导致：

但这可以被包管理器解释为 x4 是更高版本。我正在考虑给名字加后缀。因此：

ARM aarch64 世界中可能会发生类似的微架构问题。根据我的阅读，ARMv8-A 支持“高级 SIMD (Neon)”；ARMv8.2-A 支持“可扩展向量扩展 (SVE)”。这可能会产生，

有没有更好的方法来处理微架构级别的差异？

我的 Jetpack Compose Desktop 应用程序依赖于我想包含在 Debian 包中的专有可执行文件。我得到的最接近的是将文件添加为资源，但这不会设置可执行标志。

是否有另一种在 packageDeb 任务中包含文件的方法，可以保留可执行标志？