Безопасно ли переименовывать файл .deb, названный по стандартам?

Созданная структура имени .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пакет своего программного обеспечения на своем веб-сайте для прямой загрузки.

За эти годы я накопил большое количество .debпакетов с нестандартными именами, и я не помню, чтобы у меня возникали какие-либо проблемы. «Знаменитые» пакеты с нестандартными именами, с которыми люди могут столкнуться в наше время, включают google-chrome-stable_current_amd64.debи steam.deb. (В обоих случаях фиксированное имя без версии обеспечивает возможность использования стабильного URL-адреса для загрузки и стабильного имени для инструкций по установке.)

Однако я не помню, чтобы я сталкивался с пробелами в их именах; это также не должно вызывать проблем с инструментами, но это может вызвать замешательство у ваших пользователей (поскольку им нужно будет указывать имя файла или экранировать пробелы, если они используют инструменты на основе оболочки).

Еще один момент, на который следует обратить внимание: использование нестандартного имени, которое не совпадает с именем вашего пакета (как оно хранится в controlфайле), также может вызвать путаницу, например, при попытке удалить пакет (так как имя пакета не будет так же, как имя, используемое для его установки).

В результате всего этого, если вы не хотите придерживаться канонического имени, я бы порекомендовал что-то вроде my-program.debили my-program_amd64.deb(в зависимости от того, хотите ли вы поддерживать несколько архитектур). Вы также можете сделать это символической ссылкой на версионное имя файла, если хотите разрешить загрузку более старых версий.

Имена файлов стандартизированы главным образом в пользу программного обеспечения для обслуживания архивов и локального кэша.

В старые времена, до того как m68kархитектура была добавлена ​​в Debian, имена файлов использовали « package _ version .deb», без проблем. Имя архитектуры было добавлено к имени файла, когда архивное программное обеспечение необходимо было хранить i386и m68kпакеты одного пакета и версии в одном каталоге. Поскольку список пакетов всегда содержал как длинные, так и 8.3 имена файлов , это можно было бы реализовать, не нарушая клиентов.

Dpkg вообще не заботится об именах файлов пакетов вообще. Во время прогонов установки APT создает каталог со всеми файлами пакета для этого прогона установки, и каждый файл будет иметь номер в текущем прогоне, предшествующий имени файла (т. Е. Если вы устанавливаете fooверсию пакета 1 и barверсию пакета 2, что fooзависит от Апт пройдет 0-bar_2_all.debи 1-foo_1_amd64.debк дпкг).

APT обычно предполагает, что имена являются уникальными для целей кэширования. Если вы повторно используете имя, пользователи, у которых этот файл уже есть в кеше, будут пытаться возобновить загрузку, если новый файл больше по размеру, в результате чего у них останется неверный файл, который впоследствии удаляется, поскольку он не проходит проверку контрольной суммы. Однако эта ошибка отображается для пользователей, и они должны перезапустить установку.