Page 1 sur 3

Le but de ce fil de discussion est de débattre sur les avantages, les inconvénients et les améliorations qui pourraient être apportées au système de gestion de paquet. Ce message fait suite à d'autres discussions qui ont dérivées vers un troll. Je demanderai donc aux personnes qui donneront leur avis sur ce post d'uniquement participer au débat de manière constructive, nottament en ne racontant pas des installations détaillées.

jusqu'à présent, deux axes conducteur ont guidé les discussions :
- la comparaison avec le système de setup de Windows ou PC-BSD (système centralisé/décentralisé)
- la difficulté d'utiliser ce système si l'on n'est pas connecté à internet
* une comparaison des paquets et des ports (freeBSD, gentooà pourrait être utile

Et voici des idées qui ont été avancées :
* Si un logiciel n'a pas de paquet, ce n'est pas la faute du système, mais de la distribution ou du développeur.

Dans le monde windows, pour installer un logiciel, l'interlocuteur de l'utilisateur final est le createur du logiciel ; dans le monde linux (tel que je le percois), l'interlocuteur unique de l'utilisateur final est la distribution. C'est donc le role de la distrib de fournir un paquet binaire facilement installable, pas celui du createur du logiciel.

* création de paquets contenant les dépendances

* absence de "norme" et multiplicité des systèmes de gestion de paquet

* Pour juger de la supériorité d'un systeme d'installation sur l'autre, il n'y a pas que la facilité d'emploi à prendre en compte. De plus, il faut faire abstraction d'un "vécu windowzien" pour critiquer objectivement.

*manque de maturité technique en raison des plantages innexpliqués.

Enfin, pour la questoin de l'installation hors-ligne, comme solutions avancées :
* les distributions qui ont plusieur CD/dvd ont moins besoin d'internet
* possibilité de copie du cache pour la création de cd/dvd de dépot

Merci. Je récapitule donc les 10 dernières pages.

La gestion des package necessite un gros travail d'organisation pour avoir une base a jour et robuste. Bon nombre de distribution ont du mal a faire ceci, que ce soit a cause de leur politique interne ou de leur impossibilité technique. Les systèmes .deb sont sans conteste beaucoup plus avancé dans leur gestion de dépendances, quoique certains systèmes RPM arrive a revenir en ajoutant un peu de souplesse. Bémol a Mandriva.

Un autre problème est dans la gestion des librairies, partagé/pas partagé ? Lorsqu'elles sont massivement pas partagé cela crée des problèmes de plantages, de ressources systèmes et autres. Néanmoins, l'utilisation du Setup pour un nombre restreint de logiciel a été préconisé, notamment les plus éxotiques et/ou les plus système.
Dans ce cas là, ou les mettre ? Dans le /home ou dans le /opt, répertoire d'origine des installations exotiques et OPTionnel ?

Un récente distribution Linux a chamboulé totalement ce système en créant un système de fichier linké.

Une solution a été donné il y a peu par une distribution Linux récente dont j'ai perdu le nom. Celle-ci a totalement déconstruit le système de fichier originel et a a la place construit un fichier entiérement linké. En clair, un programme qu'on installe vérifie si il y a des librairie qu'il va utiliser déjà présent dans le système et dans le cas positif, va construire des link directement de son repertoire au fichier en question. Plus de librairie en trop, plus d'alourdissement du système et une certaine souplesse d'utilisation.

Maintenant, nous avons besoin d'idée pour améliorer tout ça. Le Setup facile a utiliser et mettant tout dans le repertoire utilisateur existe déjà : on le nomme Klik, mais il a des problème inhérent a l'architecture même.

Je crois que nous avons suffisament récapitulé. J'ai peut être oublié des choses importante, dans ce cas je m'en escuse platement. Avançons donc ! Des idées pour l'avenir ? :wink:

Nous ne sommes pas sur un post de problèmes techniques mais je tenais à signaler la difficulté d'installer par le biais des RPM sur Madriva 2006 Free Edition en installation "minimale". Raison invoquée : problème de dépendance pour 70% des programmes. Quand on est un débutant de linux et de la ligne de commande, c'est l'enfer. Ceci dit quand ça marche, ce n'est pas plus compliqué que sur Windows.

bonsoir

Dans le cas de figure où on a une bonne connexion internet :

je voudrais revenir sur la préconisation d'un "setup" pour les logiciels exotiques. Pour moi, je ne pense pas que "préconiser" soit le terme exact. Mon opinion (que je partage), c'est que lorsqu'un paquet existe sur les depots officels d'une distribution, l'installation par le gestionnaire de paquet est à la fois robuste et simple. C'est surement perfectible, mais dans le principe meme c'est une bonne méthode. Les difficultés commencent lorsque le logiciel n'a pas de paquet officiel, soit parce qu'il est propriétaire, soit parce qu'il est vraiment exotique. C'est la que certains voudraient que le monde linux (et donc les principales distributions) mette en place un systeme de setup. Or, du point de vue d'une distribution, il n'y a pas d'interet à developper le setup comme mode d'installation, car elle developpe déjà un mode d'installation robuste et simple : le gestionnaire de paquet. Pour qu'un logiciel s'installe ainsi, le contrat est simple : l'editeur fournit les sources. 2 cas de figures se présentent dans lesquels cette methode idylique ne marche pas. Il y a bien evidement le cas des logiciels propriétaires ; il y a aussi les logiciels libres trop confidentiels pour que les mainteneurs d'une distrib aient le temps de s'en occuper. Dans les 2 cas, c'est à l'editeur du logiciels de faire les efforts pour rendre son soft facile d'installation sous linux. Soit en proposant lui meme les paquets à la distrib (chez Debian, il suffit que quelqu'un accepte d'etre responsable d'un paquet pour qu'il soit intégré aux depots), soit en concevant lui meme l'installation de son soft sous linux. C'est uniquement la qu'on peut voir apparaitre un "setup". Il apparait donc comme systeme par defaut, mais surtout, ce setup est de la responsabilité de l'editeur du logiciel.
Un OS à base de linux a un fonctionnement totalement ouvert et respecte un certains nombres de normes d'organisation (c'est bien ca, POSIX, non ?). Dans ces conditions, il n'y a aucun obstacle technique et légal à ce qu'un editeur de logiciel crée un binaire qui s'installe en cliquant. Si des logiciels comme flash ou java restent un peu delicats à installer, c'est bien parce que les editeurs de ces logiciels refusent de les "livrer" aux distributions linux et qu'ils ont la flemme de concevoir eux-meme un programme d'auto-installation simple.

Finalement, l'installation d'un logiciel peut se passer de 2 facons (qui différencient fondamentalement linux et windows, sans exagération aucune). Partant d'un systeme d'exploitation et d'un fichier binaire (le logiciel qu'on veut installer), soit c'est l'OS qui fournit les outils pour incorporer en son sein le binaire (apt, par exemple), soit le binaire arrive avec les outils qui lui permettront de s'installer tout seul, "en force", dans l'OS (setup).

C'est peut etre pas clair, mais c'est quand meme pour ca que je ne pense pas qu'il faille "préconiser" l'utilisation du setup pour les logciels exotiques. Formuler cela ainsi, c'est sous-entendre que linux doit trouver un moyen d'installer les logiciels exotiques, alors que c'est aux logiciels exotiques de trouver un moyen de s'installer sous linux.

Jean_R a écrit:Nous ne sommes pas sur un post de problèmes techniques mais je tenais à signaler la difficulté d'installer par le biais des RPM sur Madriva 2006 Free Edition en installation "minimale". Raison invoquée : problème de dépendance pour 70% des programmes. Quand on est un débutant de linux et de la ligne de commande, c'est l'enfer. Ceci dit quand ça marche, ce n'est pas plus compliqué que sur Windows.

Donc ta critique portent (pour mandriva) :
- problème de dépendance. As-tu eu souvent des problèmes, comment sais-tu que cela concerne 70% des programmes ?
- Difficulté d'accès à la ligne de commande.

il y a pourtant des interfaces.
- Facilité d'utilisation, lorsque aucun problème n'a été rencontré.

Si possible, evitez les les réponses à la "va vite". Néanmoins, Jean_R, merci pour ta participation ; même si ta réponse aurait - selon moi - pu être plus rédigée.

C'est peut etre pas clair, mais c'est quand meme pour ca que je ne pense pas qu'il faille "préconiser" l'utilisation du setup pour les logciels exotiques. Formuler cela ainsi, c'est sous-entendre que linux doit trouver un moyen d'installer les logiciels exotiques, alors que c'est aux logiciels exotiques de trouver un moyen de s'installer sous linux.

Assez d'accord. Le principal moyen qui doit être préconisé est la création de paquets. On peut par exemple citer wine qui a pris la peine de créer des paquets pour plusieures distributions ; ou encore le dépot commercial de cannonical qui permet d'installer des logiciels non libre (et commerciaux si on s'en réfère au nom).
Mais bon, il est plus du ressort de la distribution de créer des paquets avec des sources que du développeur. C'est une idée qui a été donnée plusieures fois et avec laquelle je suis assez d'accord. En effet, autant pour les gros projet comme wine il n'est pas difficile de trouver des personnes qui utilisent les différentes distributions afin de créer les paquets ; alors qu'un développeur indépendant n'a pas forcément envie d'installer plusieures distributions pour créer les différents paquets. Bien que, un coup de alien, on peut fournir un .deb à partir d'un rpm, ou inversement ...

Ensuite il est évident que la méthode universelle d'installation sous linux est la compilation. Néanmoins cela reste souvent un chemin de croix, un coup il ya le fichier configure, d'autre fois non ... sauf quand c'est "bien fait". J'entend par là que la présence d'un setup.sh pourrait rendre l'installation par compilation pas forcément plus difficile d'accès.
Donc, en définitive ce que j'exprime là pourrait se résumer en :
- c'est plus à la distribution/communauté de créer des paquets qu'aux développeurs
- si le développeur ne propose pas de paquets, autrement dit s'il faut compiler, proposer un script d'automatisation (le setup.sh dont je parlais).

Enfin, c'est peut être l'occasion de faire la comparaison avec le système de ports utilisé par freeBSD ou gentoo. Au final, un port est une adaptation des sources à la distribution ; présenté comme cela ça ne diffère pas tellement d'une source dont la distribution aura fait un paquet. Et pourtant le système de port m'apparait plus "standard", dans le sens ou, tant sur freeBSD que sur gentoo la commande est la même : emergue ; ce qui n'empeche pas que le portage soit différent (du moins je présume que les port de gentoo ne doivent pas être les même que ceux de freeBSD).
Donc l'ouverture que je propose est : le système de port n'est-il pas la version "standardisée" des systèmes de paquet dont certaine ont parlé.

Le Port est une chose totalement différente. Alors que le système de paquet vient du monde GNU/Linux les "Port" viennent du monde BSD. C'est une ensemble de plusieurs millier de script facilitant grandement le téléchargement, la compilation et l'installation de logiciel. C'est la manière "normal" d'installer des BSD.
On peut effectivement croire qu'elle est plus "standardisé" que le système de paquet dans le sens ou elle installe les sources et non un binaire quelconque. Néanmoins, il ne faut pas oublier que le compilation prend un temps certains. Techiquement, la compilation de Gnome peut par exemple prendre une demi-journée. C'est bien si on a le temps, beaucoup moins si on est pressé.

- si le développeur ne propose pas de paquets, autrement dit s'il faut compiler, proposer un script d'automatisation (le setup.sh dont je parlais).

Le Makefile, tu crois que c'est quoi ? C'est le Setup.sh dont tu parle et dont le but est la simplification de la compilation. Si tu trouve qu'elle est compliqué, essaye de compiler sans Makefile, après tu reviendras.
La grande différence avec les Port BSD c'est la présence dans les port BSD de dizaines de script utilitaire a coté et d'un système centralisé de gestion des sources. Deux choses qui necessite de mettre les mains dans le cambouis pour porter sous Linux mais qui a été fait (CF Gentoo).

Dans ces conditions, il n'y a aucun obstacle technique et légal à ce qu'un editeur de logiciel crée un binaire qui s'installe en cliquant. Si des logiciels comme flash ou java restent un peu delicats à installer, c'est bien parce que les editeurs de ces logiciels refusent de les "livrer" aux distributions linux et qu'ils ont la flemme de concevoir eux-meme un programme d'auto-installation simple.

On en revient a la volonté des devellopeurs ;-)

.Il en manque certainement beaucoup pour nous offrir des Setup bien fait. Je donnerais un exemple simple : les programmes d'installations de jeu propriétaire sous Linux viennent a peu près tous de je-ne-sais-plus quelle boite qui avait porté nombre de jeu sous Linux. Seulement ce setup a été fait a l'époque en GTK1 (d'ou des boutons pas jolis et des machins indéfinissable).
En 8 installation de jeu proprio, je n'ai vu qu'une seule foi le setup remis a jour en GTK2. Les autres boites se fichaient si leur setup avait un vieil air des années 1995.

Le Makefile, tu crois que c'est quoi ? C'est le Setup.sh dont tu parle et dont le but est la simplification de la compilation. Si tu trouve qu'elle est compliqué, essaye de compiler sans Makefile, après tu reviendras.

Je connais le makefile. Sauf que, à mon sens, le setup.sh s'exécute uniquement avec

Code: Tout sélectionner: ./setup.sh

alors que pour un makefile il faut souvent faire

Code: Tout sélectionner: ./configure make make install

quand il ne s'agit pas de juste faire

Code: Tout sélectionner: make

Mais bon, il suffit de lire le fichier INSTALL. Mais en effet, ma remarque ne tenais pas compte du makefile.
Pas la peine d'argumenter sur les différentes façon de compiler, cela s'éloignerait trop du sujet. On peut quand même en tirer une idée en rapport avec le sujet : si le développeur ne prend pas la peine de faire des paquets, il faut au moins qu'il propose une aide à la compilation (j'entend pas là le makefile) et "standardisée" ; que ce soit un setup.sh qu'on exécute ou le trio ./configure, make, make install.

Certains ont critiqué le fait qu'il y avait des format de paquet différents, et une abscence de standard. Pour ma part j'avais cité le fait que pour les distributions utilisant les ports, la ligne de commande était identique : emergue. Ne pourrait-on pas immaginer une commande standard pour la gestion de paquet ; d'autant qu'il n'est pas dit qu'elle n'existe déjà ? Comme vous l'avez compris, je parle d'alien.

Posons le contexte. Actuellement, lorsque l'on choisir sa distribution, il faut regarder le type de paquet qu'elle utilise, et le gestionnaire associé. Néamoins, que l'on se retrouve avec .deb ou un .rpm à installer, un coup de

Code: Tout sélectionner: # alien -i mon_paquet

et ça s'installe.
Pour que les choses soient bien claire, je ne propose pas un format de paquet standard, mais une commande standard pour les installer.
Cela n'empecherait en rien les distributions de développer leur système de paquet puisque [s]alien[/s]predator (on va changer de nom pour ne pas porter à confusion) ne favorisera pas un type de paquet, mais permettra de tous les utiliser. Il suffirait qu'il y ait une norme dans la compatibilité entre les paquets (en fait elle existe peut être ?).

Actuellement alien permet de traduire les deb <=> rpm. Cela n'empeche pas la distribution de se gérer en deb, ou rpm ; il lui suffit de convertir, ou pas le paquet fournit.

Du fait de la multiplicité des types de paquet, il faudrait en sortir plusieurs. Mais si tous les format de paquet sont compatibles ou convertissables, on pourrait très bien immaginer un type de paquet générique. Comme je l'ai dit, actuellement avec alien, qu'on fournisse un .deb ou .rpm le système (qu'il soit deb ou rpm) s'en accomode en convertissant. Avec mon format générique, on fournit à l'os un .abc, qu'il convertira ensuite en .deb, ou .rpm, et se fera l'install.
Comme ça les développeurs n'auraient plus d'excuse car ils n'auraient qu'un type de paquet à fournir, et les distributions pourraient continuer à utiliser leur système de paquet. Si en plus le font-end de predator (et oui, faut suivre ^^) pouvait être commun aux distributions

Ca vous plairait pas des menu.lsd (:?) universel ?

Because dwm is customized through editing its source code, it's pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions.

Page 1 sur 31, 2, 3 Suivant[Débat]Le système de paquet

Qui est en ligne ?

Se connecter

Page 1 sur 31, 2, 3 Suivant[Débat]Le système de paquet

Qui est en ligne ?