Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
En pratique : Éviter les pièges de l'installation automatique de programmes
(Article écrit par Pierre Ardichvili et Michel Castel et extrait d'Amiga News - septembre 1993)
|
|
Les programmes d'installation automatique peuvent être des pièges de la convivialité.
Nombreux sont les programmes qui demandent un accès à divers fichiers auxiliaires :
fichiers de configuration, gestionnaires, bibliothèques, ou encore à des variables
d'environnement, ou qui demandent l'écriture d'instructions dans la séquence de démarrage.
Tout ceci peut être assez compliqué pour que les auteurs soient de plus en plus nombreux à
fournir un script d'installation, ou à recourir à l'excellent programme Installer de Commodore.
Problèmes possibles
L'ennui, comme pour tout système automatique, c'est qu'on ne sait pas toujours ce que fait ce programme,
et que son action peut avoir des effets pervers. En ce qui me concerne, je n'ai rencontré qu'une
infime minorité de cas dans lesquels l'installation automatique ne posait pas l'un ou l'autre petit
problème.
Tout dépend de la logique de l'auteur. Plus il fait de suppositions, plus son programme est potentiellement
dangereux ou inefficace. J'ai rencontré des programmes d'installation automatique sur disque dur incapables
de reconnaître autre chose que dh0:, l'auteur ayant été incapable d'imaginer qu'on pouvait appeler un disque
dur ou une partition d'un autre nom. Pas trop grave car le programme refuse de fonctionner et aucun dégât n'est
commis.
Certains programmes d'auto-installation écrivent des instructions dans la séquence de démarrage, en supposant
qu'elle s'appelle nécessairement startup-sequence, et l'emplacement des ajouts n'est pas nécessairement optimisé.
Dans le cas des systèmes 2.0 et suivants, c'est dangereux, car il y a tout intérêt à s'éloigner le moins possible
de la séquence fournie par Commodore, les instructions additionnelles seront généralement mieux placées dans le
fichier user-startup.
Il y a toujours danger à écrire n'importe quoi comme première instruction du fichier s:startup-sequence,
voyez les articles sur les virus à ce sujet.
D'autres programmes de ce type copient dans Libs: de nouvelles bibliothèques.
Ce n'est pas sans inconvénient non plus ; je vais prendre un exemple qui me permet au passage de faire un coup
de publicité gratuite pour un produit très sympathique, le Petit Amiga Illustré (PAI). L'auto-installateur de PAI
copie, entre autres, une bardée de bibliothèque dans Libs:, dans le but louable d'y remettre certaines bibliothèques
que vous auriez enlevées pour gagner de la place. Parmi celle-ci, il y a la diskfont.library. Si vous utilisez
les polices Outline, vous avez dû copier dans Libs: la diskfont.library de votre disquette 2.04 Fonts, et PAI
la remplace par la bibliothèque d'origine. Pas grave à réparer mais il faut le savoir
(que ceci ne vous empêche pas de vous abonner au Petit Amiga Illustré, si vous ne l'avez pas encore fait).
Note de Bruce Lepper : Pierre Ardichvili n'a pas parlé spécifiquement du logiciel Installer de Commodore.
Ce logiciel a été adopté par nombreux éditeurs, et il représente un pas vers la standardisation dans le domaine
d'installation de programmes sur disque dur. Son défaut (dans certains cas) est de ne pas être suffisamment clair
au début : va-t-il ou ne va-t-il pas créer un tiroir nouveau ? A gauche, Quarterback nous laisse dans l'ambiguïté.
A droite, Praxitel est plus explicite.
Pour bien faire, un programme d'auto-installation doit vous demander l'autorisation pour toute copie, et vous
avertir en détail de ce qu'il va copier avant de le faire. Idéalement, il devrait vous donner aussi l'indication
de la version du fichier qu'il va installer et celle du fichier qu'il va remplacer.
Quelle conduite adopter ?
Lisez la doc ; si elle comporte un chapitre sur l'installation, elle vous dit quel fichier doit aller où et vous
savez à quoi vous attendre. Sinon, examinez le fichier Install-machin avec un éditeur de texte. Si c'est un fichier
de commandes, il apparaîtra en clair, vous verrez ce qu'il fait. Sinon, c'est un exécutable et vous ne saurez
ce qu'il fait qu'en le lançant.
Ayez toujours, avant de lancer une installation automatique, une sauvegarde fraîche des répertoires critiques
de votre disquette ou de votre partition système (C:, Libs:, Devs:, Prefs:, S:). Ceci vous permettra, si
l'installation a des effets indésirables, de disposer d'une disquette ou d'une partition qui démarre à
coup sûr et qui vous donne votre configuration habituelle. Il est toujours ennuyeux de voir le démarrage
s'arrêter avec un magnifique Workbench tout vide et plus rien qui répond, ou de constater qu'un certain nombre
de choses ne marchent plus comme avant et de ne pas se rappeler ce qu'il faut faire pour les restaurer.
Ceci arrive très facilement dès que votre environnement de travail devient plus riche et donc plus complexe.
Une solution d'installation automatique (par Michel Castel)
Comme Pierre, j'ai aussi été confronté à ce genre de problème. De plus, ayant depuis longtemps étiqueté
les fichiers du système (en ajoutant un commentaire avec la date, version, et provenance), je n'ai
pas apprécié de me retrouver avec des versions de bibliothèques ou périphériques logiques plus anciennes.
Certains scripts d'installation vérifient la version de la bibliothèque, mais ce n'est pas tout le
temps le cas. Donc il faut tromper le système en lui indiquant l'endroit où doivent s'installer ces fichiers.
Il faut bien sûr que cette procédure soit transparente.
Pour remédier à ce problème, vous pouvez donc créer dans votre partition système un tiroir nommé "AssInstall"
contenant les répertoires C, Devs, L, Libs, Expansion, Fonts. Ensuite, ajoutez à votre user-startup
le script ci-dessous.
Assign C: SYS:AssInstall/c
Assign C: SYS:c ADD
Assign DEVS: SYS:AssInstall/devs
Assign DEVS: SYS:devs ADD
Assign L: SYS:AssInstall/l
Assign L: SYS:l ADD
Assign LIBS: SYS:AssInstall/libs
Assign LIBS: SYS:libs ADD
Assign LIBS: SYS:Classes ADD
Assign EXPANSION: SYS:AssInstall/expansion
Assign EXPANSION: SYS:expansion ADD
Assign FONTS: SYS:AssInstall/fonts
Assign FONTS: SYS:fonts ADD
|
Le "Assign LIBS: SYS:Classes ADD" ne fonctionne pas avec les systèmes inférieurs au 3.0.
La commande "Assign" avec l'option "ADD" permet d'avoir une assignation sur plusieurs répertoires
avec un ordre de priorité. Cet ordre de priorité est défini par l'ordre de déclaration des assignations.
Par exemple, si vous tapez une commande sous CLI, le système ira la chercher dans un premier temps
dans SYS:AssInstall/c et ensuite dans SYS:c. Il en sera de même pour les programmes d'installation.
En fait, depuis peu de temps j'ai remplacé ces scripts de ma user-startup par le domaine public
Assigns 1.1 sur CAM 753b.
Après avoir redémarré, si vous tapez sous CLI "dir c:", "dir devs:" ou "dir libs:"...
vous devez avoir comme résultat un répertoire vide. Par contre, si vous installez un programme comme Pro Page,
vous y trouverez les fichiers systême qu'il aura installés.
Maintenant, il vous faudra gérer ces répertoires. Vérifier si la version de la bibliothèque
ou du périphérique logique est plus récente que la version de votre système. Et le cas échéant de la déplacer
dans le tiroir système correspondant. N'oubliez pas de mettre un commentaire (version, date et provenance).
Pour voir la date et la version, il vous suffit d'utiliser la commande "Version" (voir ci-dessous).
Pour ma part, j'utilise deux commandes avec Directory Opus. "Read" pour lire le fichier et
"Comment" pour ajouter le commentaire.
Voilà, terminé pour les fichiers système. En ce qui concerne les fichiers startup-sequence et user-startup,
je me contente pour le moment de faire une copie de sauvegarde.
|
