Est-il sûr de renommer un fichier .deb nommé par les normes?

La structure établie du .debnom de fichier est package_version_architecture.deb.
Selon ce paragraphe:

Certains packages ne suivent pas la structure des noms package_version_architecture.deb. Les packages renommés par nom-dpkg suivront cette structure. En général, cela n'aura aucun impact sur la façon dont les packages sont installés par dselect / dpkg, mais d'autres outils d'installation peuvent dépendre de cette structure de dénomination.

Question:

Toutefois, ce qu'il ya des situations réelles lors de renommer le .debfichier de package est fortement un recommandé? Est-ce une pratique normale de fournir un .debnom de fichier personnalisé pour mon logiciel?

Exemple:

• My Program for Linux v1.0.0 (Pro).deb - la dénomination personnalisée
• my-program_1.0.0-1_amd64.deb - la dénomination officielle appropriée

Remarque:

Je ne prévois pas de créer un dépôt, j'héberge simplement le .debpackage de mon logiciel sur mon site Web en téléchargement direct.

Au fil des ans, j'ai accumulé un grand nombre de .debpackages avec des noms non standard, et je ne me souviens pas avoir rencontré de problème. Les packages «célèbres» avec des noms non standard que les gens pourraient rencontrer de nos jours incluent google-chrome-stable_current_amd64.debet steam.deb. (Dans les deux cas, le nom fixe sans version garantit qu'une URL stable peut être utilisée pour les téléchargements et un nom stable pour les instructions d'installation.)

Cependant, je ne me souviens pas avoir croisé aucun d'entre eux avec des espaces dans leurs noms; cela ne devrait pas non plus causer de problèmes avec les outils, mais cela pourrait créer de la confusion pour vos utilisateurs (car ils devront citer le nom de fichier ou échapper aux espaces s'ils utilisent des outils basés sur le shell).

Un autre point à noter est que l'utilisation d'un nom non standard qui n'est pas le même que le nom de votre package (tel qu'il est stocké dans le controlfichier) peut également créer de la confusion, par exemple lorsque vous essayez de supprimer le package (car le nom du package ne sera pas le même que le nom utilisé pour l'installer).

À la suite de tout cela, si vous ne voulez pas vous en tenir au nom canonique, je recommanderais quelque chose comme my-program.debou my-program_amd64.deb(selon que vous souhaitez prendre en charge plusieurs architectures). Vous pouvez également en faire un lien symbolique vers le nom de fichier versionné si vous souhaitez autoriser le téléchargement de versions plus anciennes.

Les noms de fichiers sont normalisés principalement au profit du logiciel de maintenance des archives et du cache local.

Autrefois, avant que l' m68karchitecture ne soit ajoutée à Debian, les noms de fichiers utilisaient « package _ version .deb», sans aucun problème. Le nom de l'architecture a été ajouté au nom du fichier lorsque le logiciel d'archivage devait stocker i386et m68kregrouper les mêmes packages et versions dans le même répertoire. Comme la liste des packages contient toujours des noms de fichiers longs et 8.3 , cela peut être implémenté sans casser les clients.

Dpkg ne se soucie généralement pas du tout des noms de fichiers des packages. Pendant les exécutions d'installation, APT génère un répertoire avec tous les fichiers de package pour cette exécution de l'installation, et chaque fichier aura le numéro de l'exécution en cours ajouté au nom du fichier (c.-à-d. Si vous installez la fooversion de package 1 et la barversion de package 2, qui foodépend de , apt passera 0-bar_2_all.debet 1-foo_1_amd64.debà dpkg).

APT suppose généralement que les noms sont uniques à des fins de mise en cache. Si vous réutilisez un nom, les utilisateurs qui ont déjà ce fichier dans leur cache tenteront de reprendre le téléchargement si le nouveau fichier est plus volumineux, ce qui leur laissera un fichier non valide qui sera ensuite rejeté car il échoue au test de somme de contrôle. Cette erreur est cependant montrée à l'utilisateur et il doit redémarrer l'exécution de l'installation.