Page 1 sur 71, 2, 3, 4, 5 ... 7 Suivant[débat]zip ou autoextractible ? => débat général

[takshil]

Salut tout le monde,

je voudrais juste relancer un petit débat sur les package des applications portables.

Pour le moment, on utilise le format zip. C'est un format simple et qui permet de faire des archives un minimum compressée. C'est très bien pour ceux qui ont un antivirus qui bloque le téléchargement des exécutables, etc... Et ça permet aussi à ceux se trouvant sous linux ou mac de pouvoir extraire les fichiers dans le but de préparer leur clé USB (même s'il me semble qu'on peut aussi le faire via 7zip)

Sinon, il y a une autre solution qui pourrait convenir à une grande partie des gens aussi : l'autoextractible. Les avantages c'est qu'on peut choisir le format de compression (7zip, zip, rar,etc..) cela n'aura aucune incidence sur comment la personne pourra extraire les fichiers. Actuellement, le format qui présente le meilleur taux semble être le 7zip. Donc si on utilise le format 7zip avec un taux de compression ultra, on en arrive à des archives super légères ce qui permet de descendre la charge des serveurs. Si on regarde bien, OpenOffice.org présente déjà le format autoextractible.

Donc je pense qu'on pourrait très bien mettre en parallèle les deux formats de fichiers. Mais en plaçant le format exe un peu plus en avant pour que plus de personnes le téléchargent.

Takshil

[Agent Ty]

Hello,

Ca me paraît être une bonne idée, à condition de bien préciser la différence entre les deux types de fichier et le mode opératoire, à destination de madame Michu, téléchargeuse d'applis portables.

[Tuxmouraille]

Bonjour,
Une autre solution qui nécessite d'utiliser CAFE, c'est d'utiliser les archives aux format 7z, mais avec une autre extension: fmk par exemple.
Lors d'un double clique dessus CAFE les fera ouvrir par un soft qui ce chargera de les installer au bon endroit dans la clé. Je doit pouvoir écrire quelque chose de correcte rapidement.
Voila comment le pense que l'on peut procéder.
Double clique sur le fichier .fmk => CAFE intercepte => il lance fmkinstaller.exe avec le chemin du fichier en argument => fmkinstaller à l'aide de 7zip extrait un fichier info.ini contenant les informations sur le paquet: nom, version, description, somme md5 des fichiers de l'archive, etc... et les affiche dans une boite de dialogue demandant confirmation de l'installation => si l'utilisateur est d'accord le paquet est décompressé au bon endroit sur la clé.
En bref une version Framakey de GDedi.

Si le logiciel est déjà présent dans la Framakey, il ne fait que mettre à jour le logiciel et n'efface pas les profiles.

Ca nécessite que tous les paquets soient identique dans leur structure et l'ajout du fichier info.ini.

L'idée est d'utiliser le maximum d'outils en ligne de commande déjà existant, pour ce qui n'existe pas créer les outils les plus KISS possible et s'inspirer de ce qui ce fait déjà: APT, etc...

[takshil]

Ta solution aurait pu être bien, mais en fait, ça prive tous ceux qui veulent juste avoir une application portable de pouvoir le faire de façon simple.
Disons que certains vont voir un .fmk et ne sauront pas avec quoi l'ouvrir s'ils n'ont pas pris la version totale de la framakey.

Par contre, c'est un peu l'idée qui sera utilisée pour la V2 de la framakey (en mieux même encore)

[Roromis]

L'idée de l'extension fmk, c'est pas une mauvaise idée, mais ça veut dire qu'il faut absolument avoir déjà installé la Framakey, impossible d'utiliser les applications portables à part (ce qui est un gros avantage de la Framakey par rapport à Liberkey par exemple). Je pense qu'il vaut mieux suivre l'exemple du .paf.exe de portableapps: utiliser un format existant (zip par exemple) et faire des fichiers .fmk.zip par exemple. Sa permet à n'importe qui de comprendre qu'il peux dézipper l'application sans problème, tout en permettant à l'archive d'être reconnue par CAFE.

[Tuxmouraille]

Bonjour,
Ok, un fmk.zip c'est effectivement mieux. Les idées à chaud sont pas forcement les meilleurs.

[dedenimes]

Pas forcement les meilleures en effet, mais ça fait avancer le schimiliblick.
On vient de trouver en quelques post une solution qui me parait très intéressante pour la suite, pouvoir installer ses softs directement par café, ou bien les installer à la mano.
Il va falloir se faire un petit sondage en interne pour voir si tout le monde est d'accord pour ce nouveau format de fichier (et accessoirement ça nous donnerais une occasion de revoir tous les paquets, voir les pbs avec le fichier ini manquant dans certains paquets).

Cordialement

[Tuxmouraille]

Bonsoir,
Faudrait aussi faire un empaqueteur pour être sûr que tous les paquets sont identiques.
Personnellement je ne peux coder qu'en AutoHotKey pour le moment, et je ne sais pas gérer les fichier xml. Donc par fénéantise je préférais l'ajout d'un ini pour les infos dans la fenêtre d'installation.

Petite remarque. CAFE peu gérer deux associations de fichiers par extensions, et possède son propre menu contextuel, on est pas obligé d'utiliser l'extension .fmk.zip.

[Roromis]

Bonjour,
Je suis en train de faire un gestionnaire d'application pour la Framakey en python et pygtk. J'ai préféré ne pas trop l'ébruitter pour ne pas donner de faux espoirs (je n'en suis qu'au début, et je ne suis pas certain d'arriver à faire quelque chose d'utilisable...), mais puisque la conversation dérive vers ce sujet, autant en parler avant que quelqu'un ne se lance dans un projet semblable...
Quelques captures d'écran de ce que ça donne actuellement: http://www.roromis.fr.nf/synapps.php
Pour l'instant mon programme gère à peu près l'installation et la désinstallation d'applications (ça marche, mais je n'ai pas fait énormément de tests, et je dois améliorer quelques points). Il ne reste plus que la mise à jour (le plus compliqué).

(et accessoirement ça nous donnerais une occasion de revoir tous les paquets, voir les pbs avec le fichier ini manquant dans certains paquets).

Refaire les paquets est effectivement quasi-indispensable. En cherchant à gérer les mise à jours, j'ai essayé de trouver la version d'un logiciel... Impossible de trouver un standart entre les différents applications. Parfois c'est dans un fichier version.txt, parfois dans un fichier Portable*soft*-*version*-fr.01.txt... J'ai du me résoudre à créer moi-même un fichier version.txt lors de l'installation, mais du coup la mise à jour de logiciels n'ayant pas été installé par synapps (mon application) est impossible.
Le top du top serait d'avoir, un peu comme les applications portableapps, un dossier distinct (Data) contenant la configuration, qui serait toujours le même. Ainsi, il n'y aurais qu'un dossier à conserver pour conserver toute la config.

[pyg]

Ha, voilà un débat que nous avons souvent eu par ici

Ma position (discutable) est la suivante :
Proposer 2 formats de fichiers pour la même appli me parait entrainer une forte confusion chez la plupart des utilisateurs (déjà, pour beaucoup de gens autour de nous, télécharger un fichier et installer un soft, c'est presque une aventure).
Je préfère qu'on essaie de s'en tenir à un seul format.

Partant de là : lequel ?

ZIP
+ format disponible partout (windows comme linux)
++ intégré à Windows
+ pas de blocage antivirus
++ peut s'interfacer simplement à la quasi totalité des environnements de dév
++ pour une personne souhaitant portabiliser une application, aucun logiciel (NSIS ou autre) n'est requis
- compression moyenne, voire faible, donc utilisation > de bande passante
- tout le monde ne sait pas "dézipper" (bon, ça se fait rare, quand même)

7ZIP
++ excellente compression
--- nécessite les binaires 7zip pour décompresser
+ possibilité de faire des fichiers autoextractibles avec une interface graphique (option sfx très limitée, même avec les addons externes, mais ça a le mérite d'exister)

EXE
++ les personnes ne sont pas perdues : une GUI, ça rassure
- moins souple que le zip (en amont (compilation) comme en aval (installation))
- une personne sous linux/mac qui voudrait se rajouter des applis ne pourrait pas.

Je caricature un peu, mais bon...

Si ça ne tenait qu'à moi, je dirai que le zip fait le meilleur compromis (la bande passante est devenue un faux pb : on a jamais eu de pb de ce côté là, et qui parmi vous n'est pas en haut débit ?).

Cependant, OK pour étudier d'autres solutions.
Le .7z est a exclure selon moi car il impose d'avoir préalablement de quoi dé7zipper. C'est contraire à la "Framakey Rule N°1 : l'application doit se suffire à elle même"

Dans les solutions en .exe, je verrai :
- soit une solution sur base de 7zip+SFX : on a les avantages du 7zip et de l'exe, sans les inconvénients du 7zip. Et on peut même batcher ça sous linux. Par contre, la GUI est minimaliste (probleme ou pas? je vous laisse y réfléchir)
- soit une solution basée sur NSIS

La seconde solution a ses inconvénients, mais elle à un avantage non négligeable si on prend un peu de recul : on peut "re-coller" à la norme PortableApps et du coup se dire qu'on essaie de faire d'une pierre deux coups en collant par là même à leur format de description d'application.

Comme le faisait très justement remarquer Roromis, les descriptions des applications Framakey manquent de cohérence. C'est un fait (que j'assume, même s'il vient du fait qu'on n'a jamais su se fixer une vraie norme dans la durée).

Jusqu'à présent, ce n'était pas gênant, mais aujourd'hui, ça nous gêne aux entournures pour des projets comme synapps, la Framakey 2, ou autres.

Bref, peut être est-il temps de fixer une décision, même si elle aura de lourdes conséquences...

En ce qui me concerne, je l'ai dit, j'aime le format .zip pour sa souplesse et son "universalité".
Mais s'il ne convient plus, et qu'on s'orientait vers des .exe, alors je serai pour qu'on bascule carrément vers le format de PortableApps. Cela permettrait par ailleurs d'utiliser leur outils (réinventer la roue me parait une mauvaise idée) et de mutualiser les efforts.

Le gros point faible de cette solution, c'est que le format de description (appinfo.ini) est relativement faible. Cela ne nous empêche pas soit de rajouter des infos au appinfo.ini, soit de créer un fichier spécifique framakey.xml plus détaillé, mais il faut le savoir

Si on partait sur cette solution, cela représente un travail pas très rigolo (pas compliqué, mais qui prendrait pas mal de temps) pour créer la bonne arborescence et recréer le package pour chaque appli. Je vous le dis tout net : je ne le ferai pas seul
Cependant si on a quelques volontaires motivés prêt à lire un tuto et à se partager le taf, alors c'est OK pour moi.

Comment voyez vous les choses ? (moi c'est open tant que ça ne me rajoute pas trop de boulot )