建立的文件名结构.deb为package_version_architecture.deb.
根据这段落：
有些包不遵循名称结构
package_version_architecture.deb。由 dpkg-name 重命名的软件包将遵循此结构。通常，这不会影响 dselect/dpkg 安装软件包的方式，但其他安装工具可能依赖于此命名结构。
问题：
然而，在实际情况中，重命名.deb包文件的情况是否非常严重？联合国受到推崇的？.deb为我的软件提供自定义文件名是正常做法吗？
例子：
My Program for Linux v1.0.0 (Pro).deb— 自定义命名my-program_1.0.0-1_amd64.deb— 正确的官方命名
笔记：
我是不是计划创建一个存储库，我只是将.deb软件包托管在我的网站上以供直接下载。
答案1
多年来，我积累了大量.deb具有非标准名称的软件包，并且我不记得遇到过任何问题。人们现在可能遇到的具有非标准名称的“著名”软件包包括google-chrome-stable_current_amd64.deb和steam.deb。 （在这两种情况下，固定的无版本名称可确保稳定的 URL 可用于下载，稳定的名称可用于安装说明。）
但是，我不记住遇到过任何名字中带有空格的人；这也不应该导致工具出现问题，但可能会导致用户感到困惑（因为如果他们使用基于 shell 的工具，他们需要引用文件名或转义空格）。
另一点需要注意的是，使用与包名称（存储在文件中）不同的非标准名称control也可能会导致混乱，例如尝试删除软件包时（因为软件包名称与安装它所用的名称不同）。
因此，如果您不想坚持使用规范名称，我会推荐类似my-program.deb或 的名称my-program_amd64.deb（取决于您是否想支持多种架构）。如果您想允许下载旧版本，您也可以将其设置为版本文件名的符号链接。
答案2
文件名标准化主要是为了存档维护软件和本地缓存的利益。
过去，在m68k将架构添加到 Debian 之前，文件名使用“包裹_版本.deb”，没有问题。当归档软件需要在同一目录中存储相同软件包和版本的软件包时，架构名称被添加到文件名中i386。m68k因为软件包列表始终包含两者长文件名和 8.3 文件名，这可以在不破坏客户端的情况下实现。
Dpkg 通常根本不关心包的文件名。在安装运行期间，APT 会生成一个目录，其中包含本次安装运行的所有软件包文件，每个文件的文件名前都会添加当前运行中的编号（即，如果您安装软件包foo版本 1 和软件包bar版本 2，这foo取决于， apt 将传递0-bar_2_all.deb并1-foo_1_amd64.deb传递给 dpkg）。
APT 通常假设名称是唯一的以用于缓存目的。如果您重复使用名称，则缓存中已包含此文件的用户将在新文件较大时尝试恢复下载，这将给他们留下一个无效文件，该文件随后会因校验和测试失败而被丢弃。但是，此错误会显示给用户，并且他们必须重新启动安装运行。