Je viens de découvrir par un heureux hasard un système de packages qui me parait prometteur.
Alors que je cherchais à mettre à jour ma version de Gaim sur ma mandrake 10.1, je m'aperçois que la page download du site de gaim propose, en dépit d'un rpm pour ma mdk, un format .package qui est censé s'installer sur n'importe quelle distribution !
Hop, je fait un tour sur le site en question: http://autopackage.org/(...)
et je m'aperçois qu'il y a même un installateur graphique: http://autopackage.org/gallery.html(...)
Je me dit chouette, c'est ultra simple!
Manque de bol, le package Gaim ne semble incorrect. Qu'à cela ne tienne, la première page indique d'autres logiciels proposent ce packetage dont Gimp. J'essaye donc d'installer Gimp (2.0.6)
Je rends le fichier exécutable sous Nautilus, je l'exécute, le logiciel de gestion de packetage s'installe tout seul depuis internet dans sa dernière mise à jour, le front end Gtk de même. Même pas le temps de dire ouf que Gimp marche sur mon PC. Il se met tout seul dans le menu. Une installation à la Windows mais avec encore moins de Ok à cliquer (pas de license, pas de repertoire d'install...). Juste une demande de mot de passe root pour l'installer pour tous les utilisateurs (au choix)
Je suis sur le cul. Un seul fichier pour n'importe quelle distrib. Aucune ligne de commande. Un front-end sympa et clair (Qt ou Gtk). Seules ombres au tableau, l'install ne tiens pas compte des rpms déjà installés et la désinstallation nécessite une ligne de commande simple: "autopackage remove gimp2" au lieu d'un front end.
L'avenir serait-il un gestionnaire de packages qui intègrent ces packages avec ceux de la distrib (rpm, deb...)?
Journal Autopackage
7
jan.
2005
# Vivement que ça se démocratise
Posté par pierthi . Évalué à 5.
Je trouve aberrant d'avoir plusieurs packages différents pour une même architecture (au hasard Linux/x86) à cause des spécificités des formats de packages, quand en plus on doit supporter différentes architectures. Je pense que les développeurs ont vraiment autre chose à faire, et attendre qu'une bonne âme veuille bien packager leur appli pour une distrib, c'est une perte de temps et un gachis de ressource.
Il m'arrive souvent de vouloir tester la dernière version de tel ou tel logiciel, mais me taper 72 heures de compilation (avec parfois toutes les dépendances ...), pour moi qui ait une machine banale, un système banal, c'est clairement 71 heures 59 minutes et 50 secondes de trop.
Reste à espérer que ça se démocratise, et qu'on ne réinvente pas (trop) la roue avec 15000 installateur de packages. En tous les cas, ils ont l'air d'avoir compris la problématique les développeurs, ce qui me parait encourrageant. Au moins que de temps serait gagné pour certains, et de très loin pas les moins nombreux ...
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par THE_ALF_ . Évalué à 7.
Un package universel pour tous ? Berk. ça me rappelle les installations à la Windows. Comment va-t-il gérer les dépendances ? Me mettre par défaut toutes ses librairies à l'arrache en espérant que ça passe ? Et se retrouver comme sous windows avec des tonnes de DLL dont on ne sait rien ? Devoir répondre à des questions ésotériques du style "le programme veut remplacer un DLL existant par une autre version, continuer (o/n)" ? Et comment va se passer la désinstallation ("êtes vous sur de vouloir virer xyz.dll version npq ? Attention, des fois d'autres logiciels risquent de plus marcher mais on s'en fout, on vous préviens") ?
Et je ne parle pas du problème de sécurité posé par l'éxécution d'un exécutable tiers _en_root_. Lorsque j'installe un rpm ou un deb, je ne lance qu'un exécutable bien connu (rpm, dpkg, apt-get, etc...) en root, et je sais qu'il va se contenter de copier des fichiers sur mon ordi, et que je pourrais tracer tous ces changements et revenir facilement en arrière. Comment je contrôle ce qu'il fait, cet exécutable provenant d'on ne sait où ?
Conclusion, un tel système de pakage est un énorme retour en arrière, en direction de Windows... retrouver l'enfer des installations/désinstallation de Windows, très peu pour moi. Je préferes utiliser alien par exemple, qui me permet de transformer par ex. les .rpm en .deb, et donc d'installer sans trop de problèmes (modulo en général le réglement des dépendances à la mano... ce qui est une _bonne_ chose lorsqu'on introduit un logiciel qui n'a pas été gentiment packagé pour votre ordi) la plupart des logiciels non Debian... en tapant seulement un "sudo alien -i trucmuche.rpm".
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par olosta . Évalué à 7.
D'abord que les systèmes de paquetage soient différent suivant les distribs n'est pas un problèmes mais ils pourraient être compatibles (citez moi un système de paquetage qui fait un truc completement différent des autres). Il ne devrait y avoir que des paquets binaires, sources et sous un seul format. Il y a assez d'autres fonctionnalités pour se démarquer : Interface, rapidité, méthode de récupération...
Les OS libres ont pris une avance extraordinaire sur Windows dans ce domaine. Il ne reste pas grand chose pour enfoncer le clou complètement. D'ailleurs le portage d'un système de paquetage (style dpkg/apt) sous Windows existe t'il ? Je me demande si ce ne serait pas interessant que les gens puissent utiliser ca sur leur Windows, trouvent ca pratique et qu'on puisse leur annoncer que en passant à Linux c'est tout le système qui serait mis à jour de cette façon.
Une dernière remarque sur ton argumentation : les problèmes de sécurité d'un système de paquetages sont les même, car si toi tu lance un outil que tu connait. Celui ci utilise des scripts et des programmes binaires qui se trouvent dans le paquet. A partir de la tu n'est plus sur de rien. Donc installer un paquet sous Windows ou sous Linux présente les mêmes risques. Existe t'il un système de paquetage qui assure une sécurité (certification du paquet, vérification de ce que font les scripts d'installs...)?
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par TImaniac (site web personnel) . Évalué à 5.
Existe t'il un système de paquetage qui assure une sécurité
Les repositories sous nux proposent généralement le chiffrement par clé des packages, c'est déjà un bon gage de sécurité, après évidemment il faut faire confiance au site au question.
Les OS libres ont pris une avance extraordinaire sur Windows dans ce domaine.
Ils traînent également un gros boulet : pas de système unifié, et ça c'est un retard également extraordinaire qui en fait chier plus d'un.
Enfin je finirais par dire que Windows n'est pas vraiment en retard dans le domaine, la possibilité de versionning des assemblies .NET permet de gérer avec finesse les dépendances, d'avoir plusieurs versions qui cohabitent sans problème, avec en autre un Global Assembly Cache facile à localiser, permettant d'installer facilement une application, aussi bien sous Windows que sous Linux avec Mono : pas de différence entre les distri, ce qui facilite drôlement le déploiement. (désolé fallait bien que je fasse encore un peu de pub ;-) )
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par Maclag . Évalué à 3.
Euh... j'ai peur de dire une bêtise, mais c'est pas le but de la LSB?
Sinon, je pense qu'il est évident que les paquets binaires ne pourront pas être les mêmes pour toutes les distributions, parce que chaque équipe est libre de développer sa distrib comme elle le sent, et c'est tant mieux! Je suis pour la conservation d'une certaine diversité.
Ce qui serait franchement bien, par contre, ce serait une sorte de meta-paquet source, accompagné de scripts et de librairies en plusieurs versions, capable de pondre tout seul, en compilation, des paquets pour différentes distribs en allant vérifier tout seul les dépendances appropriées à chaque distrib. euh... c'est clair? j'espère que oui... par contre, réalisable, ça je ne sais pas.
Parce que oui à la diversité, mais bon, trouver des mainteneurs pour chaque logiciel, c'est pas toujours évident (d'ailleurs si qqun connait un moyen simple de faire un nvu_0.6 qui va bien avec le mozilla debian... ;) )
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par soulflyb (Mastodon) . Évalué à 4.
Je vais être assez direct, mais : ça commence à me saouler tous ces gens qui veulent porter tous les avantages des linux sous windows en croyant naïvement que cela va les inciter à passer sous linux.
Détrompez vous, cela est complètement faux !
Voilà un an que je mène une petite expèrience, et le résultat est plutôt concluant : j'ai monté deux pc pour deux personnes différentes et je leur ai mis linux en leur expliquant les avantages, la philosophie, etc ... de toutes façons ils n'avaient jamais eu de pc, donc n'avaient pas vraiment d'habitudes.
Résultat ?
La première personne a quand même installer windows (tout en gardant linux) pour utiliser sa carte tv, mais elle l'a trouvé impossible à utiliser, pas intuitif, trés compliqué... elle a abandonné et est retournée sous linux rapidement. Cette personne ne joue pas du tout, ce qui explique qu'elle n'a pas du tout besoin de windows.
La deuxième personne, au contraire, joue énormément. Pas de problèmes : elle bascule sous windows uniquement pour jouer. Elle est plus à l'aise sous linux que sous windows, trouve le système d'installation nettement plus simple sous linux, etc...
En parrallèle, j'ai installé à mon père la tripotée de logiciels libres classiques : firefox, thunderbird (j'ai eu du mal à le convaincre pour ce dernier), gaim, open office... en lui disant que ce sont les même sous linux. Il les a tous adoptés mais que je lui dis de passer sous linux, j'ai le droit à ce superbe argument : "c'est trop compliqué", que je démonte en 30s (cf plus ex plus haut), mais à cela, je ne peux rien répondre : "non, je n'ai pas le temps, et de toutes façons tu m'as dit que c'étaient les mêmes logiciels que ceux que j'utilise"
Alors, porter certains logiciels sous windows pour des problèmes d'interopérabilité (je pense à OOo) : oui. Mais porter les avantages de linux (firefox, kde (sisi, il y en a qui veulent porter kde !!), le système de paquetages, xemacs (encore une hérésie)....), je ne vois pas du tout l'intérêt, c'est une perte de temps et cela va à l'encontre de la philosophie GNU.
Mon humble avis.
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par gnumdk (site web personnel) . Évalué à 7.
>tiers _en_root_. Lorsque j'installe un rpm ou un deb, je ne lance qu'un exécutable
>bien connu (rpm, dpkg, apt-get, etc...) en root, et je sais qu'il va se contenter de
>copier des fichiers sur mon ordi
On voit bien que tu n'a jamais regardé le contenu d'un package. Faire un rpm qui lance un gros rm -rf / ou qui installe une backdoor sur ta machine, c'est loin d'etre difficile ;) Alors bon, autopackage ou rpm, c'est la meme chose.
>Comment va-t-il gérer les dépendances ? Me mettre par défaut toutes ses
>librairies à l'arrache en espérant que ça passe ?
Ben, je confirme, sur mon linux, j'ai des tonnes de librairies dont je ne sais rien ;)
gnumdk@milouse:~$ ls /usr/local/lib | wc -l
65
gnumdk@milouse:~$ ls /usr/local/kde/lib | wc -l
30
De plus la méthode autopackage est plutot propre, il telecharge lui meme les dépendances manquantes aux formats autopackage, les installes et propose surement de les désinstaller. Pour l'utilisateur final, je trouve ca tres bien, ca permet de mettre à jours un logiciel sans attendre que la distributions le fasse(jamais) et sans avoir à compiler. Je pense que c'est une tres bonne chose pour l'utilisateur final. De plus, cela n'interfere pas avec le systeme de package rpm ou dpkg.
Bien sur, c'est beaucoup moins bien sur des logiciels plus complexe comme apache ou autre car l'utilisateur aura un truc non intégré à l'os à la fin. Mais pour un truc comme gaim ou mozilla, c'est tres tres bien! De plus, permettre à l'utilisateur de tout installer dans son home dir me parait une bonne chose.
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par Frederic Bourgeois (site web personnel) . Évalué à -1.
C'est contradictoire avec
De plus, cela n'interfere pas avec le systeme de package rpm ou dpkg.
Si il installe lui même des librairies au format autopackage, que deviennent les libs de la distrib ? en doubles ? écrasées ?
C'est, peut-être, pratique mais propre je doute
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par gnumdk (site web personnel) . Évalué à 3.
Il suffit que les gens qui package le truc mette ca dans le .desktop de l'appli:
Exec=LD_LIBRARY_PATH=/usr/local/autoinstall/lib gaim
Et voilou, je vois pas en quoi c'est sale.
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par Frederic Bourgeois (site web personnel) . Évalué à 4.
Tu as les libs spécifiques de Gaim, mais les autres ...
Un soft n'est pas constitué uniquement de ses propres libs, par
exemple il peut utiliser libldap ou perl (une version bien précise),
une distrib est étudiée pour avoir une cohérence avec ces differentes versions.
Comment Autopackage peux-il travailler en étant indépendant de la distribution ?
Comme je le disais plus haut les libs sont certainement en doubles ou bien remplacées.
Moi je ne trouve pas ça très propre
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par gnumdk (site web personnel) . Évalué à -3.
Autopackage fournis toutes les librairies dont l'appli a besoin!
Gaim a besoin de libldap(par ex), ben autopackage télécharge le version autopackage de libldap et l'install dans /usr/local/autopackage/lib(par ex) ou dans ~/lib . Par contre, si libldap est deja fourni par l'os, alors autopackage ne fait rien :p
Donc, oui tu as sur le disque deux version de libldap si t'avais deja une version moins ressente et incompatible installée: une dans /usr/lib(dpkg) et une autre dans /usr/local/autopackage pour autopackage.
Mais ca, tu peux pas faire autrement, si j'install une logiciel récent à la main, je risque obligatoirement d'avoir des librairie à mettre a jour. Pour pas casser l'existant, ben j'installe ca dans /usr/local et je fait un LD_LIBRARY_PATH=/usr/local/lib par ex.
Donc, autopackage ne fait rien de plus que ca que tu ferais à la main en installant une logiciel récent sur une distribution n'ayant pas les librairies adéquates. Sauf que l'a y'a rien à compiler.
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par Frederic Bourgeois (site web personnel) . Évalué à 0.
Merci
Donc, oui tu as sur le disque deux version de libldap si t'avais deja une version moins ressente et incompatible installée
ça J'adore ...
En conclusion j'avais bien compris, merde alors ?
Donc, autopackage ne fait rien de plus que ca que tu ferais à la main en installant une logiciel récent sur une distribution n'ayant pas les librairies adéquates. Sauf que l'a y'a rien à compiler.
Oui, mais moi je ne trouve pas ça propre
Laisse tomber avec moi, merci ...
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par gnumdk (site web personnel) . Évalué à -5.
Super, effectivement, avec une logique comme ca, tu aurais pu éviter de poster des le début ;)
Tu aurais peut etre un argument à donner(sur le pkoi c pas propre) ou c'est juste une question d'esthétique?
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par Yann Hodique (site web personnel) . Évalué à 3.
Accessoirement, installer des lib n'importe où (je me réfère à ton /usr/local/autoinstall/lib), ça implique qu'on n'est pas capable de retrouver les composants d'un programme en se référant au FHS (Filesystem Hierarchy Standard). Même chose que précédemment, on peut se moquer des standards, mais je trouve compréhensible de trouver ça important. Moi par exemple, même en tant que simple utilisateur, ça me gênerait.
Sinon, off-topic, mais t'es quand même sacrément agressif dans tes réponses.
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par gnumdk (site web personnel) . Évalué à -2.
>réponses.
Désolé, j'avais pas l'impression.
>avec X versions de la même lib en des endroits différents parce que les
>programmes les cherchent en des endroits différents
Je vois pas bien le probleme la. En quoi c'est génant d'avoir plusieurs version de la librairie installé sur un systeme? Dans le cas de /usr/local/autopackage/lib par exemple, si je lance un logiciel packagé avec ma distrib, jamais il n'ira chercher la bas sa librairie. Donc cela n'a aucun impact sur le systeme.
>Accessoirement, installer des lib n'importe où (je me réfère à
>ton /usr/local/autoinstall/lib), ça implique qu'on n'est pas capable de
>retrouver les composants d'un programme en se référant au FHS
En quoi c'est plus difficile qu'avec /usr?
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par Yann Hodique (site web personnel) . Évalué à 4.
Un exemple de problème, c'est par exemple l'absence de mise à jour automatique. La bibliothèque installée sur le système recevra une mise à jour de sécurité, qui sera royalement ignorée par ton programme puisqu'il a sa version dans son coin. Il ne faut pas oublier que dans "bibliothèque partagée", il y a quand même... "partagée". Pour faire ça, autant tout compiler en statique, au moins là les choses sont claires.
[^] # Re: Vivement que ça se démocratise... Mon Dieu OUI !
Posté par Anthony F. . Évalué à 3.
Le fait que ce soit non standard n'est AMHA pas une excuse, "il n'y a qu'à" ! Un standard est rarement le point de départ d'un progrès, c'est plutôt l'aboutissement. Ca tends vers le HS, mais pour situer je préfère des applis non standards qui m'apportent un réel progrès (ergonomie, fonctionnalité, ...), plutôt qu'un standard qui n'est utilisé que par ses concepteurs par parceque ça n'apporte rien... (je n'ai rien en tête quand je dis ça)
Le problème de sécurité est lui aussi un "non-problème" (la encore AMHA), puisque ce n'est plus à la distribution d'assurer sa propre sécurité, mais à l'application. Par exemple, quand j'installe FireFox 1.0 sous Windows - dès sa sortie, sans la moindre bidouille, et sans provoquer d'instabillité du système -, je ne compte pas sur Windows pour colmater FireFox quand un patch va sortir, mais sur FF (qui intègre justement un mécanisme de mise à jour auto).
Dans ce cas, pourquoi ne pas inclure directement dans AutoUpdate la gestion des mises à jours de sécurité des versions de bibs partagées.
C'est certain, 2 mondes s'affrontent :
- les vieux de la vieille qui utilisent Linux depuis longtemps et à qui rien ne fait peur, pas même d'utiliser Phoenix 0.5 sous IceWM.
- les noob qui viennent du monde Windows et qui ne comprennent pas pourquoi c'est si "lourd" d'installer un FireFox 1.0 sur une Ubuntu qui n'est fourni avec un "déjà trop vieux FireFox 0.9.3"
[^] # Re: Vivement que ça se démocratise... Mon Dieu OUI !
Posté par Yann Hodique (site web personnel) . Évalué à 3.
Je ne suis pas tout à fait d'accord avec ton exemple de Firefox. Mon argument précédent n'était pas que j'attendais une prise en charge de l'application Firefox, mais plutôt celle de la libpng par exemple (au hasard) : quand la libpng du système est mise à jour, ça m'arrange que toutes les applis qui utilisent du png soient protégées. Tout simplement parce que en tant qu'utilisateur de base je ne suis pas sensé connaître toutes les dépendances d'une appli, ni même réaliser la gravité d'une faille. Alors l'inclusion des mises à jour des libs, très bonne idée, mais on perd exactement tout ce qui semble faire l'intérêt de la chose pour certains, puisque bien sûr pour pouvoir tester l'existence d'une lib, il faut la mettre dans un endroit précis, ou avoir une base de données globale. Et finalement on a réinventé un rpm ou un deb.
Pour ce qui est de l'affrontement des 2 mondes, je dirais juste que les vieux de la vieille, comme tu les appelles, ont probablement de bonnes raisons de s'accrocher à leur système, et que ce n'est pas par pur masochisme qu'ils font des choses "compliquées". Simplicité et fiabilité font rarement bon ménage.
(au passage les vrais hommes restent en console ;))
[^] # Re: Vivement que ça se démocratise... Mon Dieu OUI !
Posté par Anthony F. . Évalué à 1.
Arf, on parle bien de stations de travail là hein ?! Troll effronté : a là là, ces fonctionnaires, ils trouvent toujours un moyen de faire croire que leur travail est compliqué alors que depuis longtemps les vraies secrétaires du privé utilisent Word et Excel pour être efficace... mais dès que le directeur a le dos tourné, les fonctionnaires utilisent Word et Excel comme tout le monde pour partir plus tôt...
:-P
Trève de plaisanterie (ma maman est fonctionnaire...) : pour libpng, je ne maîtrise pas assez linux, mais qu'est-ce qui empêche d'avoir d'un côté la distribution qui gère ses propres problèmes (noyau, KDE/GNOME/..., gestionnaires de conf, ...) et de l'autre un système bien distinct de gestion des applicatifs et de leurs problèmes ? Si 2 applications utilisent plusieurs versions de libpng, ça se complique un peu, mais ce n'est pas à la distribution de gérer ce conflit et de mettre en péril sa propre stabilité si une de ces librairies est mise à jour par une installation...
(j'ai l'impression de me répéter en ce moment moi, c'est peut-être que le sujet ressurgit de plus en plus souvent, cf quelques post précédent sur d'autres journaux)
Je pense que si une "Debian Desktop", mise à jour tous les ans voir moins (hors failles), mais avec un système d'installation séparé des applications de type FireFox 1.1 et OpenOffice 2.0 qui sont prévus pour mars, serait encore plus appréciée qu'une "Ubuntu" qui a prévu de sortir tous les 6 mois et va donc manquer le coche de ces 2 sorties "majeures" (et donc repousser de 6 mois leur utilisation). - pas très claire cette phrase à rallonge -
L'utilisateur novice d'Ubuntu Hoary désireux d'utiliser OOo 2.0 rapidement va donc devoir bidouiller et risquer de planter son environnement pour mettre à jour "une simple application" ? Je suis choqué que ça ne choque personne... ;-)
[^] # Re: Vivement que ça se démocratise... Mon Dieu OUI !
Posté par Yann Hodique (site web personnel) . Évalué à 3.
La distribution est une entité complète et cohérente (ou du moins devrait l'être), qui garantit à l'utilisateur qu'en n'utilisant rien d'autre que ce qui est fourni, tout marchera (modulo les bugs, of course), et que si ce n'est pas le cas on le préviendra et on lui dira quoi faire pour corriger le tir. D'où l'importance d'avoir une offre logicielle conséquente. Avec le logiciel libre, on a la chance de pouvoir tout centraliser dans un même distributeur, ça serait vraiment du gachis de ne pas le faire.
Telles qu'elles existent actuellement, les distributions mettent bien l'accent sur le fait que si tu t'écartes du chemin tracé (en compilant un truc, ou en installant un package non supporté) c'est ton problème, et ça ne les regarde plus. En agissant ainsi (en contrôlant l'utilisateur donc), on parvient à avoir un système stable.
Maintenant, imaginons qu'une distribution laisse à l'utilisateur l'applicatif (à définir), il n'y a plus de contrat de fiabilité, puisque quoique veuille faire l'utilisateur, il doit sortir de la distribution. Fatalement, l'utilisateur installera tout n'importe comment, ne mettra rien à jour et ses programmes planteront, il y aura des virus. Pour lui, c'est "Linux" qui aura failli, il n'a aucun moyen de réaliser que c'est en grande partie sa faute.
Vraiment j'espère qu'aucune distribution ne fera ce pas pour séduire le public. L'installation de logiciels est un acte d'administration, et c'est important que la personne qui l'exécute en soit consciente. Ça ne la rendra pas plus compétente (quoique c'est même pas dit) mais ça la responsabilisera. La difficulté de la tâche (enfin faut pas exagérer quand même) ne fait que refléter la complexité qu'il y a à garder une cohérence.
Quant au fait de planter son environnement... ça fait 4 ans que j'ai la même Mandrake cooker (avec des softs bien à jour donc), et j'ai eu très peu de problèmes. Mais ces problèmes, je les avais cherchés, c'était les miens, et je savais les résoudre. Je n'ose pas imaginer l'état des forums si on avait mis tous les packages "applicatifs" cooker à la disposition de toute le monde sans avertissement préalable. Ça aurait été un carnage. Tout ça pour dire qu'installer OOo2 dans un environnement qui n'a pas été testé avec est risqué, et qu'il est important d'en avoir conscience.
Désolé, je suis un peu verbeux ce soir :-)
[^] # Re: Vivement que ça se démocratise... Mon Dieu OUI !
Posté par Anthony F. . Évalué à 2.
Pas grave, moi ça me va :-)
A priori, nos points de vues dépendent entièrement de l'utilisateur concerné :
- En entreprise, la vision distribution est effectivement la meilleure.
- Pour un utilisateur de base, ca passe, jusqu'au jour où il veux installer la dernière version de "Logiciel" parceque sur le site "Logiciel.com" il est dit que "ça marche mieux".
- Pour un utilisateur averti (en info, mais pas en Linux), c'est vraiment galère car il veux toujours les dernières versions de X, Y et Z pour "s'amuser" !
C'est de ce dernier dont il était question dans mes propos, et tu admettras que "actes d'administrations" sur des machines perso, c'est pas vraiment approprié...
En fait, je comprends très bien la vision "distribution", mais sur certains points je n'aime pas cette méthode car elle rend dépendant de l'éditeur de la distribution. Cela pose même un problème pour les éditeurs de logiciels libres car certaines distributions customisent un peu trop, provoquant de plus en plus souvent des bug spécifiques aux distribs : c'est le cas de OOo et de Mozilla qui ont autre chose à faire que de debugguer le code des autres... (je l'ai lu je sais plus trop où)
A mon sens, si des éditeurs de logiciels pour Linux arrivent en masse avec des projets importants et à évolution rapide, la vision de distribution va avoir du mal a résister si un moyen simple n'est pas trouvé : je doute qu'il soit possible pour des organismes de gérer autant de packages qu'il y a de distributions et même de versions de distributions.
Comment ça se passe sur MacOS X lorsqu'un utilisateur (avec les droits) veut installer FireFox 1.0 ou pire Internet Explorer ?
[^] # Re: Vivement que ça se démocratise... Mon Dieu OUI !
Posté par Mildred (site web personnel) . Évalué à 1.
Je suppose qu'il télécharge un petit fichier .dmg avec safari et le monte (les fichiers .dmg sont des images diques). Dedans, il y a un dossier dont le nom se termine par .app. Avec son Finder, il va le copier dans le dossier /Applications
Lorsque il veut le lancer, il double-clique sur le dossier .app
je n'ai pas vérifié pour les applications que tu donnes mais c'est comme ca que ca fonctionne pour gimp-2.2 sur OS-X (malheureusement, j'attends toujours gimp-2.2 sur ubuntu :-( )
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par Mildred (site web personnel) . Évalué à 1.
C'est pour cela que chez autopackage ils prévoient d'inscrire le programme dans la base de données dpkg/rpm/... pour permettre notament une désinstallation facile et peut être une mise à jour (mais comme dit dans une réponse, ce n'est pas à la distrib de mettre à jour mais au programme)
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par Gilles Gagniard (site web personnel) . Évalué à 6.
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par gnumdk (site web personnel) . Évalué à 3.
> centralisé, chaque paquet autopackage aura son propre gtk (2.2.10 ici,
> 2.4.11 la, 2.4.13 encore ici) parce que chaque autopackage aura une
> dépendance sur un gtk un peu différent ... sans compter le gtk du système.
Faux! Va voir sur le site ;)
Si autopackage detecte la presence d'un gtk compatible sur le systeme, il ne le reinstalle pas. Dans l'avenir, il devrait meme etre capable d'appeler le gestionnaire de package pour gérer les dépendance manquante si ce dernier a les packages souhaité.
Apres, comme dit plus haut, c'est clair que y'a pas de mise a jour de sécu.
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par Jean Canazzi . Évalué à 2.
C'est pour etre sur de bien comprendre hein...
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par Anthony F. . Évalué à 2.
- peut-être que chaque appli dispose de son propre répertoire de bibliotèques partagées dans Autopackage. Dans ce cas ce ne sont plus des bib partagées, mais avec les capacités des disques actuel je ne suis pas certain que ce soit un problème pour un simple utilisateur...
- ou alors il suffit de voir si des liens existent encore sur cette bib. Si chaque appli dispose d'un lien, tant que le nombre de lien est supérieur à 1, ne pas effacer la bib quand on désinstalle une appli.
"Parole d'un noob curieux", donc si je dis des grosses bétises, tapez pas trop fort :-P
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par wismerhill . Évalué à 2.
Mais justement, comme on n'utilise pas ici le système de package de la distribution, il ne peut pas savoir qu'il y a encore des programmes installé par autopackage qui sont liés à cette lib.
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par Mildred (site web personnel) . Évalué à 1.
> C'est pour etre sur de bien comprendre hein...
Au hazard: Autopackage inscrira son programme dans la base de données du gestionnaire de paquets de la distrib et donc le paquet sera désinstallé avec les autres.
C'est dans la TODO list je crois
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par Hugues Hiegel (site web personnel) . Évalué à 2.
le système de packages offert par ta distrib, il est centralisé.
si tu choisis d'avoir des sources non officielles pour obtenir d'autres packages, tu prends le risque de te retrouver avec des binaires vérolés, mais au moins ça reste relativement cohérent avec ta distrib car ça a été généralement pensé pour.
dans l'idée où tu n'as pas les packages pour une appli donnée, il te reste donc les sources pour recompiler une appli et l'installer dans /usr/local si tu es quelqu'un de consciencieux et méthodique.
le système autopackage n'est pas si mal que ça en soi, mais si c'est pour installer dans /usr/local des binaires que je n'ai PAS compilés moi-même et qui ne sont donc pas en cohérence avec mes librairies, il va installer lui même d'autres librairies et au final l'ensemble est forcément sale.
en clair : soit tu choisis un système de packaging cohérent, et tu optes pour les sources et le triplet ./configure && make && make install, soit tu utilises autopackage et tu n'as pas de système cohérent : dans 6 mois, un an, voire plus, tu te retrouveras avec un disque dur surchargé de librairies inutiles. chose qui me rappelle furieusement un certain OS.
Jusque là, je n'ai fait grosso modo que traduire l'état d'esprit de celui à qui tu posais (intelligemment, hein) la question, et cet avis se rapproche beaucoup du mien.
Cependant, je pense que tous ces problèmes n'auraient pas lieu d'être. S'il existe des outils tels que alien ou, mieux rpm2cpio + cpio, je trouve qu'autopackage en soi est une excellente idée. Reste à voir ça de plus près (je parle pour moi) et à voir quelle différence il propose par rapport au format cpio, qui est à mon sens totalement indépendant de la distrib...
si autopackage exécute des scripts de pré/post installation, alors je dis "non". Car il est tout simplement impossible de faire des shellscripts de gestion de packages qui soient portables sur TOUTES les distributions. Rien que pour t'en convaincre, jette un oeil à la manière dont chacune d'elles gère le système d'init ...
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par Mildred (site web personnel) . Évalué à 1.
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par Croconux . Évalué à 10.
Tout à fait d'accord. Sous Windows, on se tape une procédure d'installation différente pour chaque logiciel avec cliquage sur "Next" à répétition. A chaque fois que je dois installer une machine Windows pour un copain ça me saoûle de devoir installer chaque logiciel un par un : On met le CD, on clique sur "Next", on reboute, on met le CD suivant, etc. Il est très difficile d'automatiser tout ça à moins de faire carrément un ghost de toute la config. Avec n'importe quelle distrib Linux on choisit ce qu'on veut installer on clique sur "install" et on peut aller faire autre chose.
Conclusion, un tel système de pakage est un énorme retour en arrière, en direction de Windows...
C'est une tendance récente. Il y a un ou deux ans les gens sui passaient sous Linux le faisaient pour trouver quelque chose de différent. Ajourd'hui on a une arrivée en masse d'utilisateurs qui veulent un Linux qui ressemble trait pour trait à Windows sinon "ce n'est pas intuitif". Ca mène à des projets comme XPDE. Récemment sur Ubuntu il y a eu un grand débat sur le Ctrl+Alt+Supr. Certains utilisateurs souhaitent que ce raccourci ouvre le "System Monitor" comme sous un autre OS. Et va vas-y que je te sort mes arguments "c'est plus intuitif", "c'est facile à retenir", "c'est plus simple". Intuitif? Non. Simple? Non. C'est juste comme Windows, point.
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par Sébastien Bonnefoy (site web personnel) . Évalué à 3.
Plus sérieusement, je vois pas bien ce qu'apporte autopackage par rapport à mon apt-get (moyenant une IHM pour l'utilisateur lambda). Et il ne faut pas se faire d'illusion, c'est pas ca qui va régler les problèmes de packaging sur les différentes distrib... Ca ne fait que rajouter un nouveau format.
RMP ou deb, c'est aussi la diversité qui fait la force de notre OS favoris, même si ca coute en packaging pour les développeurs ou les gestionnaires des packets des différentes distribs.
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par Gniarf . Évalué à 4.
ce que veulent vraiment les gens qui découvrent Autopackage et équivallents, c'est un repositery unique de logiciels et librairies à télécharger. un seul point d'entrée, parce que c'est plus simple à configurer et à utiliser.
pour eux, les utilisateurs pressés qui ne veulent pas perdre de temps, pas lire de docs, rien, et que ça se configure tout seul à la souris, et d'invoquer des excuses diverses sur le thème "sous Windows c'est comme ça" "sans ça on ne pourra pas faire venir les utilisateurs Windows" alors que c'est leur confort à eux auquel ils pensent en premier.
et c'est évidement aux développeurs et packageurs de se mettre d'accord et de faire marcher ça et tout et tout. ah, il faut que ça soit fait pour hier, parce que sous Windows il suffit de cliquer sur setup.exe et tout va bien, et cela, depuis 10 ans.
on a donc d'un côté des gens avec une mentalité de consommateurs, et de l'autre coté, des gens avec une mentalité de producteurs.
bizarrement, elles ne se recoupent pas.
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par Mildred (site web personnel) . Évalué à 1.
Ce n'est pas un format de paquets comme les autres. Il est prévu pour des logiciels tiers uniquement qui sont souvent packagés un peu tard sur les distribs ...
Exemple très simple: le jour ou OpenOffice 2 sort, je vais l'installer. Il ne sera surement pas disponible en .deb alors j'espère pouvoir trouver les binaires sur le site OOo.
Si OOo existe en autopackage, au lieu de décompresser OOo dans /opt/OpenOffice2/ je lancerait le paquet Autopackage et je lui dirais de l'installer dans /opt/OpenOffice2/
Personellement, je trouve ca plus simple. Evidamment, lorsque OOo existera en .deb, je l'installerait et je pourrais virer l'autre.
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par Alex . Évalué à 2.
CA devient uniquement interessant si autopackage se "standardise".
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON ! et pourtant...
Posté par pierthi . Évalué à 1.
Ah ? avoir un format de package qui pourrait simplifier la vie des développeurs et des utilisateurs serait un pas vers Windows ? Beaucoup de points sont certes mauvais sous Windows, mais je doute que les concepteurs de ce genre d'outil ne sont pas au courant des lacunes qu'ont les installateurs de Windows. En tous les cas, leur FAQ est assez claire et leur format laisse une grande liberté au développeur (ce sont des scripts bash).
Inutile de préciser que le but de ce format n'est pas de remplacer les formats de packages RPM, DEB et co. Loin, mais alors très loin de là. Un des plus gros avantage que je peux voir, c'est de s'épargner la compilation du dernier logiciel de la mort qui tue, au lieu de se farcir la sainte trilogie "configure && make && make install" (et donc s'affranchir d'avoir un environnement de développement complet, notamment les lib qui sont parfois très très lourdes), car il y a beaucoup de chance à l'heure actuelle que les développeurs et les utilisateurs aient la même architecture (au hasard Linux/x86).
Le problème de la sécurité est un faux problème et la "pollution" de l'arbre des packages peut être évité en installant dans une arborescence spécifique (à la /usr/local pour les compilés main).
Cela permettra de tester rapidement un logiciel (comprendre: installer pour de bon pour ceux qui ne veulent pas se prendre la tête) et permettre aux puristes de l'installer aux petits oignons par la suite.
Si des personnes sont motivées pour fournir des packages adaptés à leur distribs, tant mieux. Mais le but n'est pas que de simplifier la vie des utilisateurs, mais ausi celle des développeurs, qui certainement ont autre chose à faire que de s'intéresser aux spécificités de chaques distribs.
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par Psychofox (Mastodon) . Évalué à 2.
Juste pour dire, la plupart des installers et tous les msi peuvent être installés en mode "silencieux". Il suffit de rajouter les arguments. Par exemple, si tu as un CD avec une compilation de programme que tu installes sur plusieurs machine, tu peux y inclure un fichier batch qui les installes tous automatiquement. Et pour les msi, tu peux créer des .mst (transforms) qui permettent de garder des choix types.
Sous windows, ce n'est pas vraiment les choix techniques qui posent problème dans la gestion des installations d'applications, c'est le fait qu'on évolue dans un monde propriétaire ou chaque éditeur propose sa procédure d'installation, que ce n'est pas forcément documenté et donc, que les applications ne sont pas forcément simples à repackager, puisqu'on n'a pas les sources et qu'on ne sait pas forcément ce dont le logiciel a besoin.
PS: mon boulot actuel consiste à repackager des applications pour des déploiements automatiques sous windows via l'Active Directory
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par Erwan . Évalué à 3.
C'est utile par exemple, pour:
* Les projets qui veulent fournir des binaires sans packager pour 36 distributions. Ca n'empeche pas les distributions de faire leurs paquets, comme elles avaient l'habitude.
* Les logiciels commerciaux qui de toutes facons sont binaires.
D'habitude on avait des tgz qui s'installent dans un repertoire, un systeme d'installation automatique propre au systeme en question, au pire, des rpms.
Bref, c'est complementaire.
# juste pour etre taquin :
Posté par Gniarf . Évalué à 3.
(et on passera sous silence les rêves hallucinés de Java et Java Web Start avec leurs binaires évidement portables partout...)
[^] # Re: juste pour etre taquin :
Posté par Yhar Gla . Évalué à 2.
# service zero-install start
Mounting zero-install filesystem mount: le point de montage /uri/0install n'existe pas [ECHEC ]
Starting zero-install daemonzero-install: readlink(/uri/0install/.lazyfs-cache): No such file or directory
zero-install: Can't find location of cache directory. Make sure /uri/0install is mounted and that you are running the latest version of the lazyfs kernel module. [ECHEC ]
Quand je charge à la main le module lazyfs0d1d25 ça ne change rien...
En revanche Java Web Start je l'ai déjà essayé et ça marche. Maintenant pour une utilisation quotidienne, je ne sais pas ce que ça donne.
[^] # Re: juste pour etre taquin :
Posté par Mildred (site web personnel) . Évalué à 1.
# Hum
Posté par cho7 (site web personnel) . Évalué à 7.
L'idéal serait de commencer d'abord par se mettre d'accord sur les dossiers standards d'installation, car ca diffère selon les distributions.
[^] # Re: Hum
Posté par Matthieu BENOIST . Évalué à 10.
C'est bizarre, ça me rappel une histoire d'anneau, ça.
-
trois .rpm pour les Rois noobs sous le ciel
sept .deb pour les geek dans leurs caves
9 .tar pour les slackwareux, destinés au trépas
[un format pour le seigneur ténébreux sur son sombre trône
Un, format pour toutes les distrib, un format pour trouver les dependances
Un format pour les upgrader toutes, et dans les problèmes les lier
Au pays de Linux ou s'étendent les problèmes de dep.
mouaif. bon, en fait, j'vais sortir, moi...
Mitsuaki, trollfarceur
# Politique
Posté par Zorro (site web personnel) . Évalué à 5.
C'est pour ça qu'à mon avis, à moins d'une sérieuse pression de la part des utilisateurs, la situation est pas prête de bouger.
Depuis combien de temps existe Zero Install ? Pourquoi aucune distro complètement basée dessus (à ma connaissance) ?
[^] # Re: Politique
Posté par Yhar Gla . Évalué à -1.
# Conclusion
Posté par eon2004 . Évalué à 4.
1. Les utilisateurs puissent avoir accès facilement à un logiciel. Est-il normal que l'on ait pas accès aux dernière version de Gaim et Gimp sous Mdk 10.1 alors que les version Windows sont sorties depuis longtemps.
2. Réduire la tâche des développeurs à compiler des packages pour chaque distrib
3. Augmenter la façilité de diffusion des "petites" distribs
La diversité des distribs est nécessaire et sera toujours présente. Néanmoins, ne peuvent-elles pas s'entendre sur un format unifié plutôt que d'augmenter le fait que les logiciels ne soient disponibles sous forme de package seulement pour une minorité des distribs.
Je verrais bien un package "standard" qui s'installerai sur un systène "standard". (LSB...je ne sais pas si ça a quelque chose à voir). Chaque distrib voulant installer ce paquet le modiefierais à sa sauce lors de l'install selon ses préférences et particularités.
[^] # Re: Conclusion
Posté par tomachaka . Évalué à 2.
On aurait ainsi entre une install standard (sur une lfs par exemple) ou bien autopackage install --with-rules mandrake10.1_Official ...
[^] # Re: Conclusion
Posté par eon2004 . Évalué à 3.
Lors de l'installation, la distrib récupère l'icone et le champ catégorie et fait ensuite sa tambouille elle-même pour présenter le logiciel dans son menu selon ses préférences de classement, mettre son icone sur le burau ou non, dans la barre du lanceur, etc...
On peut extrapoler ce système au répertoires d'installation. La distrib sachant où serait installé le logiciel sur une distrib "standard", elle pourrait à loisir choisir de l'installer autre part selon ses préférences.
[^] # Re: Conclusion
Posté par Thomas Maurin (site web personnel) . Évalué à 1.
Si le boulot d'une distrib se limitait à ça, elles perdraient beaucoup de leur intérêt et un abonnement au club Mandrake deviendrait plus qu'optionnel.
# mouais
Posté par Éric (site web personnel) . Évalué à 5.
Le problème dans la compatibilité des RPM n'est absolument pas le format RPM lui même. Sinon DEB et RPM seraient dors et déjà super compatibles. Ils savent déclarer ce dont ils ont besoin, les urpm/yum/apt savent lire ça et aller chercher les dépendances. Ils savent aussi présenter une interface graphique si besoin tout en gardant la compatibilité avec les outils de base.
Qu'est ce que fait de plus ce système de package au niveau technique ? probablement rien du tout.
Si les RPM ont dérivés pour être spécifiques au contenu c'est à cause de leur contenu et des dépendances ou compilations spécifiques, ou de l'intégration des composants (icones, choix par défaut ...). Changer de système de package n'y changera rien.
Désolé mais c'est un doux rêve et ce qu'ils mettent dans leur "autopackage" ils étaient déjà capable de le mettre dans des RPM ou des DEB (on en voit des RPM qui sont relativement compatibles). S'ils n'ont pas été capables de le faire en RPM ils vont vite se rendre compte que changer le conteneur amènera les mêmes problèmes (avec en plus un défaut d'intégration puisqu'il faudra gérer ce package séparément des autres, comme c'est déjà beaucoup reproché à nvidia).
[^] # Re: mouais
Posté par eon2004 . Évalué à 2.
# L'idée que je me fait ....
Posté par Anonyme . Évalué à 3.
Comme il est dit au premier post, c'est très bien pour installer des applications tierces. Après lecture des commentaires ci dessus, on voit bien que pour un système de package pour une distribution, c'est loin d'être l'idéal.
Reste que je suis d'accord avec pierthi, pour des applications tierces c'est idéal, même s'il faut installer plusieurs version des même libs (d'où le manque d'intéret pour une distrib complète)
# faut qu'on m'explique la
Posté par nomorsad . Évalué à 0.
C'est donc si difficile de faire un rpm ou un deb? autopackage est-il réellement plus facile à utiliser pour faire un package?
Reste l'interface graphique... J'utilise parfois le panneau de config mandrake pour installer des logiciel et une fois l'avoir montrer à des newbies, ils y arrivent très bien tout seul.
Remarque moi je suis pas embeté, j'ai tout mes logiciels relativement rapidement, et meme des logiciels non-libres grâce au systeme d'ebuild Gentoo...
Et puis un rpm c'est pas pour installé "absolument" sur une Mandrake ou sur une redhat (suse aussi je crois). C'est fait pour s'installer sur un ordinateur qui gere ses logiciels avec le programme rpm. Et de meme pour les autres soft d'installations.
alors rpm, deb, portage ou autopackage.. A l'ouest, rien de nouveau...
Ouaipa!
Monkey Boy
--
Grace à la ligne de commande, j'ai réapris à communiquer avec mon ordinateur...
[^] # Re: faut qu'on m'explique la
Posté par Mildred (site web personnel) . Évalué à 2.
On peur remarquer que ce n'est qu'un script shell. Je l'execute et j'ai directement droit à une jolie interface GTK2 pour l'installer ou je veux.
Je ne dirais pas que c'est un système de paquets mais un système qui permet de créer facilement un programme d'installation sous linux pour des applications tierces.
Et c'est à mon avis nécessaire car la plupart des logiciels libres ne sont pas facilement installables sous linux lorsque ils ne sont pas packagés (jattend toujours Gimp 2.2 sur ubuntu alors qu'il est déja disponible pour MacOS-X et Windows).
Ce qui m'embête le plus depuis que je suis passée à linux, c'est que je ne peux pas avoir les dernières versions des logiciels libres phares comme sur Windows. C'est dommage.
# Parfait pour les logiciels proprio
Posté par tanguy_k (site web personnel) . Évalué à 1.
Comme les libs sont incluses avec le logiciel, l'entreprise qui commercialise son logiciel sous Linux n'a pas a se soucier de la compatibilite de son logiciel avec tel ou tel distrib. Dans l'etat actuel des choses, les entreprises ne supportent qu'une seule distribution et meme qu'une seule version de celle-ci, avec ce systeme ca ne serait plus le cas.
Mais c'est clair que ca serait pas cool que toutes les applications libres sous linux embarquent leurs propres libs C/C++ et le reste.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.