Чи безпечно перейменовувати .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, імена файлів використовували " пакет _ версія .deb", без проблем. Ім’я архітектури було додано до імені файлу, коли програмне забезпечення архіву, необхідне для зберігання i386та m68kпакунків одного і того ж пакету та версії в одному каталозі. Оскільки список пакунків завжди містив і довгі, і 8,3 імена файлів , які можна було б реалізувати, не порушуючи клієнтів.

Dpkg взагалі не переймається іменами файлів пакетів. Під час запуску установки APT генерує каталог із усіма пакунками файлів для цього запуску установки, і кожен файл буде мати номер у поточному виконанні, попередньо призначений до імені файлу (тобто, якщо ви встановите fooверсію пакета 1 та barверсію пакета 2, що fooзалежить від , схильний буде проходити 0-bar_2_all.debі1-foo_1_amd64.deb до dpkg).

APT зазвичай передбачає, що імена є унікальними для кешування. Якщо ви повторно використовуєте ім'я, користувачі, які мають цей файл у своєму кеші, вже спробують відновити завантаження, якщо новий файл буде більшим, що дозволить залишити їх недійсним файлом, який згодом буде відкинутий, оскільки він не зможе перевірити контрольну суму. Однак ця помилка відображається користувачеві, і їм доведеться перезапустити установку.