Equivalents aux fichiers '.msi' et 'setup.exe' dans Debian ou Ubuntu?

Cette réponse explique .msiet setup.exerépertorie les fichiers d'installation d'une application sous Windows.

Existe-t-il des équivalents .msiet des setup.exefichiers dans Debian ou Ubuntu? Les .debfichiers de package correspondent-ils à .msiou setup.exeou à autre chose?

software-installation deb

— StackExchange pour tous
source

Je ne sais pas pourquoi vous posez cette question, alors je dirai ceci comme un commentaire général pour quiconque rencontre cette question. Bien qu'il existe des moyens d'installer le logiciel "manuellement", la manière préférée par la plupart des distributions Linux (et fortement recommandée) est d'installer le logiciel via le gestionnaire de paquets. De cette façon, vous obtenez automatiquement des mises à jour de sécurité et un certain niveau de test est effectué pour garantir la compatibilité avec la distribution. Si vous avez besoin de la dernière et de la meilleure version du logiciel non disponible dans les référentiels principaux, utilisez un référentiel communautaire (par exemple un PPA dans Ubuntu), mais utilisez toujours le gestionnaire de paquets.

— Muzer

Il n'y a pas de .setupfichiers sous Windows, voulez-vous dire setup.exequel est le nom typique d'un programme d'installation?

— gronostaj

Voir la apt-getpage de manuel et les documents liés à partir de là. Il n'y a même pas d'équivalent sous Windows apt-get install, et encore moins essentiellement toutes les autres choses qu'il peut faire.

— 2017

@jthill, c'est faux. Ce n'est pas aussi complet ou aussi populaire que apt-get, mais les versions récentes (Win7 et supérieures) de Powershell OneGetvous permettent d'installer Chocolatey(un équivalent à Homebrewsur Mac). Ils sont peut-être moins populaires que leurs équivalents 'nix, mais dire qu'il n'y a pas d'équivalent sur Windows est manifestement incorrect.

— 2017

@ Tim: cette question ne peut pas répondre raisonnablement sans vous préciser ce que précisément vous entendez par « équivalent ». Quelles sont les propriétés spécifiques des .msifichiers et des installateurs qui vous intéressent? Quels sont les critères précis pour déterminer si quelque chose est "équivalent" ou non? Par exemple: les installateurs ne sont que des programmes comme n'importe quel autre programme. Il n'y a absolument rien de spécial dans un programme nommé setup.exe. Depuis setup.exeest juste un programme comme tout autre programme, et Debian certainement fait un concept de « programme », considérez-vous que l' équivalent? Sinon, pourquoi pas?

— Jörg W Mittag

Réponses:

Probablement plus proche d'un programme d'installation MSI que d'un setup.exe, un .debpackage comprend une arborescence de fichiers à copier dans le système de fichiers, ainsi qu'une collection de hooks avant et après l'installation à exécuter (entre autres). Les hooks peuvent effectivement faire n'importe quoi sur le système, y compris quelque chose que je ne pense pas avoir vu sur Windows: ajouter des utilisateurs pour un service système. Une chose qu'ils ne peuvent pas faire est d'installer un autre .debpaquet - la base de données est verrouillée pendant l'installation, donc cela ne peut être réalisé que par le biais de dépendances. L'installation d'un .debpackage produit ensuite des entrées dans une base de données centrale des packages installés pour faciliter la maintenance.

Le ttf-mscorefontspackage est intéressant en ce que le package lui-même ne contient qu'un script pour télécharger et installer les polices. Ce script est exécuté dans l'un de ces crochets.

Plus près de setup.execela, le téléchargement du code source d'un programme à partir de la page d'accueil du projet, puis son exécution ./configure && make && sudo make install, ou toute autre méthode que les auteurs ont décidé d'utiliser. Étant donné que cette méthode n'ajoute pas le package à la base de données des programmes installés, sa suppression ultérieure peut être beaucoup plus difficile.

Une autre différence est que a .debspécifie ses dépendances, de sorte qu'une installation correcte peut être garantie. Pour autant que je sache, dans le monde Windows, un MSI ne peut pas provoquer l'installation d'un autre MSI, il setup.exeest donc généralement utilisé pour ce type de suivi des dépendances. Plusieurs commentaires notent que les MSI peuvent nommer des dépendances, mais comme il n'y a pas de base de données centrale de MSI comme il en existe pour les .debpackages, le fait de manquer une dépendance entraînera un échec de l'installation.

Ainsi, un .debest en quelque sorte entre un programme d'installation MSI et un setup.exe. Le package peut faire tout ce qu'il veut pendant ses hooks avant et après l'installation, peut nommer et trouver généralement ses propres dépendances, et laisse un enregistrement de son installation dans un emplacement central pour faciliter la maintenance.

— Renard
source

Sous Windows, les programmes d' setup.exeinstallation de style s'intègrent également au système d'installation suivi (avec les programmes de désinstallation, etc.). Avec MSI et les programmes d' .exeinstallation, les dépendances sont gérées en incorporant la dépendance dans le programme d'installation ( par exemple, le programme d'installation redistribuable VC ou le programme d'installation DirectX) et en installant des DLL de dépendance à côté de l'exécutable (ou en tant qu'assemblys système). Il en setup.exeva de même pour .deb. L'équivalent de la construction à partir de la source est également la construction à partir de la source sous Windows ;-).

— Stephen Kitt

Je ne fais rien qui rapproche les MSI des paquets Debian que les exécutables de configuration: un MSI ne peut pas installer un autre MSI, tout comme un paquet Debian ne peut pas installer un autre paquet (sauf via ses dépendances).

— Stephen Kitt

@StephenKitt: -les setup.exeinstallateurs de style ne sont en aucun cas "suivis" par le système d'exploitation à moins qu'ils exécutent des MSI en dessous (puis les MSI sont ceux suivis). Le fait qu'ils disposent d'une clé de registre de désinstallation n'a aucun rapport avec cela. Cela revient à dire que chaque fichier est suivi car il est répertorié dans le système de fichiers.

— user541686

MSI peut et souvent (dans les produits plus gros) a des dépendances, cependant, étant donné qu'il n'y a pas de référentiel central de .MSI, généralement ce qui se passe lorsque vous manquez une dépendance est qu'ils refusent d'installer.

— Matteo Italia

"quelque chose que je ne pense pas avoir vu sur Windows: ajouter des utilisateurs pour un service système". Je suis assez certain que les programmes d'installation de SQL Server, IIS et Visual Studio le font. Mais cela pourrait être moins évident car le modèle des utilisateurs de Windows est un peu plus raffiné que le modèle Unix / Linux par défaut (que vous soyez root ou que vous ne l'êtes pas) ..

— MSalters

Les programmes d'installation binaires à fichier unique que j'ai vus sur Linux étaient des .shfichiers qui contenaient un script shell concaténé avec un blob binaire, comme ceci:

#!/bin/bash
tmpdir=$(mktemp -d /tmp/installer.XXX)
tail -n +6 "$0" | tar -xJf - -C "$tmpdir" || exit 1
sudo "$tmpdir/setup.sh"
rm -rf "$tmpdir"
exit
[binary content follows]

Ceci est essentiellement équivalent à celui setup.exequi s'auto-extrait également dans un dossier temporaire et exécute le véritable programme d'installation à partir de là.

— Dmitry Grigoryev
source

Tiré de: /ubuntu/13415/what-are-run-files/13416#13416

Un fichier .run est normalement un programme personnalisé qui doit être exécuté pour installer un programme. ceux-ci ne sont généralement pas pris en charge car ils ne suivent pas où vont les fichiers et ne fournissent normalement pas de méthode de désinstallation. il n'y a aucun moyen d'être sûr de ce que le script fera sur votre système, ils sont donc considérés comme dangereux.

Ils sont proches du fichier exe windows et en tant que tels viennent avec les mêmes problèmes.

— Zumo de Vidrio
source