Vers l'idéal d'un système de paquets universels

109 · Le 13/02/2006, à 20:22

/!\ ARTICLE À L'ÉTAT DE BROUILLON /!\

Le but de ce post est de recenser et d'analyser tous les projets qui sont susceptibles de permettre l'utilisation d'un logiciel sur n'importe quelle distribution Linux récente, sans devoir passer par l'enfer de compiler un binaire pour chaque distribution existante. N'hésitez pas à apporter votre pierre à l'édifice afin que ça soit le plus complet possible. Ce fil est également un lieu de débat sur la meilleure manière de standardiser le schmilblick.

Nous aurions donc :
- d'un côté, le dépôt centralisé des applications testées, approuvées, corrigées et packcagées par les mainteneurs de la distribution (ce sont les .deb, .rpm, scripts emerge et autres .tgz)
- de l'autre une manière simple, universelle et efficace d'installer la version "brute" toute droit sortie du site de l'application ou d'un CD-Rom de magazine ou d'un jeu commercial. C'est à fin d'utiliser des logiciels qui ne sont pas encore dans les dépôts, ou des versions plus récentes, ou encore des logiciels commerciaux.

Comme vous le voyez il ne s'agit pas de mettre en cause le système de paquets existant, mais de proposer un complément. Réduire le nombre de compilations et avoir un système fonctionnant sur toute distribution est une aubaine à la fois pour les petits projets aux ressources et à l'espace web limités, pour les entreprises désirant proposer des logiciels pour Linux, et pour l'utilisateur qui ne se cassera plus la tête parce que tel logiciel n'est pas dispo dans le bon format de paquet. Let's troll

- AUTOPACKAGE

Présentation :
"Autopackage, est une infrastructure multi-distributions de paquetage d'applications pour Linux."

Avantages :
* fonctionne sans rien avoir à installer préalablement
* outils de gestion existant en français et disponibles en GTK et QT
* x86 et x86_64
* Mise à jour possible
* L'application installée pourra être agrémentée de plug-ins et autres extensions
* Gère le multilinguisme
* Gestion des dépendances (limitée)

Inconvénients :
* Non disponible pour PPC, SPARC et autres architectures
* Nécessite une connexion internet
* Se lance à partir d'un terminal
* Trop de paquets dont l'installation ne fonctionne pas
* Pas d'intégration avec le système de paquets (prévu pour la version 1.0)

- ZERO INSTALL

Présentation :
"Le sytème Zero Install ne se contente pas de rendre plus facile l'installation de logiciels : il la rend inutile. Les utilisateurs lancent leurs applications directement depuis le site web de l'auteur du programme. La mise en cache assure, après le premier lancement, une rapidité d'exécution égale à celle d'une application installée de façon conventionnelle, et permet l'utilisation hors-ligne."

Avantages :
* disponible en module du noyau
* pas besoin de l'accès root
* intègre les dépendances disponibles sur le site de l'auteur du programme qu'on veut installer
* pas de disctinction entre les distributions
* pas d'installation
* pas besoin de retélécharger toute l'application si un autre utilisateur l'a déjà utilisée (partage du cache)
* option off-line
* sécurisé par vérifications MD5 et GPG du logiciel, qui de plus tourne en espace utilisateur
* option permettant de lancer (et d'enregistrer dans le cache) l'application depuis un CD ou une clé USB pour ceux qui n'ont pas de connexion web (mais le CD doit quand même avoir rapatrié les fichiers depuis le web)

Inconvénients :
* Utilisation déroutante (ligne de commande indiquant l'emplacement du script zeroinstall pour l'application choisie)
* Injecteur (graphique) moche
* En anglais seulement
* N'intègre pas toutes les dépendances (GTK et cie)
* L'auteur doit écrire le script 0install correspondant (simple fichier XML)

- KLIK

Présentation :
klik apporte une manière aisée de télécharger et d'utiliser des logiciels pour toutes les distributions majeures. Il existe actuellement 3 distributions ayant le client klik préinstallé : Kanotix, openSUSE (SLICK amélioré), et CPX-MINI.

Avantages :
* intégration avec le système

Inconvénients :
* x86 seulement
* trop peu de distributions compatibles
* Limitation à 7 applications Klik tournant en même temps (dû au système de fichiers utilisé : cramfs), sauf si on utilise FUSE
* l'nstallation hors ligne (depuis un CD, une clé USB, etc) n'a pas l'air d'être possible

- OBLISK

Présentation :
"OBLISK, (Open Binary Linux/GNU Install System Kit), a pour but de rendre n'importe quel paquet installable sur n'importe quel système GNU/Linux moderne. Les paquets OBLISK sont contenus dans une sorte d'appdir (NDT : comme Mac OS X) ; ils peuvent donc être lancés directement, mais incluent également un programme permettant de les installer dans /usr ou n'importe quel autre dossier."

Avantages :
* On peut lancer l'application de n'importe où
* On a le choix d'installer ou pas
* Les dépendances sont incluses

Inconvénients :

- LOKI

Présentation :

Avantages :
* Rien à installer préalablement
* Gestion des mises à jour et des suppressions grâce à des utilitaires graphiques optionnels
* Possibilité d'ajouter des extensions aux programmes installés
* Bonne compatibilité

Inconvénients :
* réservé aux jeux
* interface très moche (c'est du GTK 0.5 ou quoi ?)
* manque de langues disponibles
* Création laborieuse, réalisée seulement par Loki et pas par les développeurs du soft
* On doit encore passer par la console pour installer

-LSB RPM

Présentation :
Le format de paquets RPM tel que défini par la LSB, tendant à être un standard. On peut faire des RPM statiques afin d'inclure les dépendances.

Avantages :
* Standardisé
* Gérable par toute distribution en conformité avec la LSB
* Développeurs souvent plus habitués à créer des RPM que des autopackage et cie
* La connexion au net n'est pas requise, on peut très bien avoir le paquet sur n'importe quel support de stockage

Inconvénients :
* Est-ce que la version utilisée de GCC ou de je ne sais quoi peut poser des problèmes ?
* Demande les droits d'administrateur
* Doit s'intégrer avec le système de paquets utilisé par la distribution sous peine de créer un beau bazar
* Question des mises à jour (si un paquet LSB RPM inclus les dépendances liés statiquement, ces fichiers vont-ils rester lors d'une mise à jour du paquet par le système de paquets traditionnel de la distribution ?)
* C'est aux développeurs de chaque distribution de s'occuper de la bonne gestion de ces paquets par leur système, à eux de régler les problèmes de l'intégration avec APT, emerge, pacman ou trucmuche

- BITROCK INSTALLER

Présentation :
"BitRock InstallBuilder vous permet de créer des installeurs multi plate-formes simple d'utilisation, pouvant être exécutés aussi bien en mode graphique qu'en console, ainsi qu'en tant que simple utilisateur."

Avantages :
* vraiment multi-plate-formes (PPC compris)
* gère le multilinguisme
* intégration et gestion des dépendances
* intégration avec les RPM (intégration avec les DEB en cours de développement)
* solide et éprouvé
* Installateur graphique qu'il est pas moche

Inconvénients :
* propriétaire et (très) cher, inabordable pour les petits projets
* gestion des mises à jour ?

- MAKESELF

Présentation :
"makeself.sh est un petit script shell générant une archive .tar.gz auto-extractible depuis un dossier. Le fichier résultant aura la forme d'un script shell (beaucoup d'entre eux ont une extension .run), et peuvent être lancés comme tels. L'archive s'extraira dans un dossier temporaire et une commande prédéfinie (optionelle) sera exécutée (un script d'installation par exemple). Le principe est semblable à celui des archives générées avec WinZip Self-Extractor sous Windows. Les archives Makeself incluent également des checksums pour vérifier leur propre intégrité (CRC et/ou MD5 checksums)."

En bref ça ressemble à un script Loki, sauf que là il n'y pas pas Loki pour se taper l'écriture des scripts d'installation/suppression (et qu'il n'y a pas les utilitaires Loki non plus).

Avantages :

Inconvénients :
* On passe par la console
* On doit se taper les scripts à la main
* Pas d'intégration avec le système

- KONVALO

Présentation :

Avantages :

Inconvénients :

C O N C L U S I O N S
À mon avis des paquets "standardisés" comme les RPM définis par la LSB devraient intégrer des dépendances pour être fonctionnels sur une majorité de systèmes. Un préfixe/suffixe peut également leur être associé (comme "" ou "-lsb-" par exemple) pour éviter des problèmes avec le système de paquets de la distribution (il me semble que ce point est spécifié dans la LSB). Zero Install et Oblisk me semblent prometteurs, en ce qu'ils ne nécessitent pas les droits d'administrateur et que la connexion au net n'est pas un impondérable à leur fonctionnement. À plus ou moins long terme klik peut proposer la même chose avec une compatibilité satisfaisante, et il est l'un des systèmes les plus connus, malgré ses limitations (besoin de FUSE si on veut pouvoir lancer plus de 7 applications klik en même temps). De plus je pense que pour qu'un système se standardise vraiment il devrait être "supporté" officiellement, par la LSB ou du quelque chose du même genre (les récompenses reçues par klik peuvent entrer dans ce cadre).

A N N E X E S
+ The user interface vision [en]
+ klik : comparaison avec d'autres systèmes [en]
+ LSB 3.0 Package Dependencies [en]
+ Zero Install: What's wrong with APT? [en]
+ Zero Install comparé à d'autres systèmes [en]

PS : Si je fais une page de wiki je la mets dans "doc" ou dans "applications" ?

Dernière modification par 109 (Le 15/02/2006, à 05:02)

jpaul · Le 13/02/2006, à 20:27

oui

wam · Le 13/02/2006, à 20:29

ah tu m'apprends des trucs, je ne connaissais que autopackage. Franchement, avec synaptic et alien qui fonctionnent comme ils le font, au pire je compile, le format universel ne me soucie pas trop. Mais si il y en avait un, j'aimerais que son extension soit .exe

Vous en pensez quoi? c'est pris par personne ça? si?

Sinon, je pense que ça ferait une bonne page de wiki en effet

Dernière modification par wam (Le 13/02/2006, à 20:30)

killdog · Le 13/02/2006, à 20:32

bien je suis fan qu'on nous propose du choix...

et +1 pour wiki

wam · Le 13/02/2006, à 20:38

enfin, tu as pas trop le choix quand même, tu vas pas installer les .rpm

Moi je pense que le package universel, c'est pratique pour les appli qui ne sont pas dans les dépots (beta, ...)

requiem · Le 13/02/2006, à 20:42

wam a écrit :

le format universel ne me soucie pas trop. Mais si il y en avait un, j'aimerais que son extension soit .exe

Dans l'esprit des gens, .exe, c'est une extension pour les exécutables.
L'utiliser pour une archive, c'est louche.
C'est comme si tu renommais une archive zip en .jpg parce qu'elle contient une photo.

artemis · Le 13/02/2006, à 20:44

J'espere que cela marchera car je pense que c'est un véritable problème de ne pas pouvoir installer les mêmes paquets d'une distribution à une autre, c'est dommage car il suffirait d'une seule sorte de paquet pour que l'on puisse se les passés de distrib à distrib, il faut armoniser tout ça sinon rien que les éditeurs vont bouder linux, imaginer de faire un rpm pour mandriva un autre pour fedore etc et le problème double avec les deb un pour debian, un pour ubuntu etc, (en plus ce n'est pas fini car il y 'en a d'autre (evidemment ))

Ce n'est pour moi pas très efficace et j'espere que les projet vont reussir à grandir et prendre plus de place dans les distribs, imaginer il suffirait pour un developpeur de crée un seul paquet et tout le monde pourra en bénéficier et je vous parle pas de la nouveauté qui arriverait plus rapidement.

Dernière modification par artemis (Le 13/02/2006, à 20:48)

wam · Le 13/02/2006, à 20:50

Le problème, c'est que les distrib ne fonctionnent pas toutes de la même façon.
Tu peux faire des paquets où tu as tout et où l'installe reconnait ton sytèle (Ubuntu par ex) et t'installe ce qui se rapporte à ton système. Mais alors, tu vas vite te tirer avec des paquets énormes, sorte de gros dossier avec les paquet de toutes les distrib du monde dedans.

Pour que ça marche, il faudrait une standardisation en profondeur, et la standardisation, ça fait peur dans le libre

L'autre solution est de passer par le net et, après avoir reconnu ton sys, de télécharger ce qui se rapporte à ton système. Mais alors, t'as intérêt à avoir le net.

@requiem: c'était un peu une blague

Dernière modification par wam (Le 13/02/2006, à 20:52)

Oublieuse · Le 13/02/2006, à 23:32

En tous cas l'idée est séduisante... En tant qu'utilisatrice je trouverais ça vraiment pratique. A savoir si c'est possible... et c'est vrai que s'il faut uniformiser toutes les distrib', ça n'est pas une bonne chose, il me semble que c'est justement la diversité qui fait la richesse du libre. Mais bon je n'y connais rien en informatique, je ne vois pas du tout ce que ça impliquerait un système universel.

mars · Le 13/02/2006, à 23:33

bah c'est vrai que ca permettrait certainement, si on avait ca, aux sociétés editrices de logiciel de fournir des précompilés plus simplement utilisable! MAIS :
ils ont déja visiblement du mal a unifié le systéme universel donc c'est pas demain la veille que ca sera adopté a mon avis. Puis pour que cela soit adopté il faudrait qu'il regroupe les avantages de tout les systémes d'installation :
- gestion des dépendances aussi bonne que les .deb
- facilité de création a la maniére des rpm
- possibilité d'installation par les sources (avec gestion des dépendances et des flag) a la maniére des ebuild gentoo
- serveur de dépots commun pour toutes les distrib avec possibilité pour chaque distrib de modifier le paquet si elle le souhaite!

bref tout ca c'est les premiéres conditions que je vois pour que TOUTES les distrib puissent accepter ce systéme! sans parler du changement ENORME que ca impliquerais et des autres désirs tordu que pourrait souhaiter les développeurs. Bref c'est pas demain la veille... par contre les .deb prennent ainsi que les ebuild pour leur facilité a réaliser une importance de plus en plus grande.

skateinmars · Le 14/02/2006, à 00:50

On pourait parler des .run meme si ce ne sont pas vraiment des archives

wam · Le 14/02/2006, à 01:01

Oublieuse a écrit :

Mais bon je n'y connais rien en informatique, je ne vois pas du tout ce que ça impliquerait un système universel.

ah bon? Pourtant tu cotoies un système quasi universel depuis le début de ta vie, il s'appelle windows. Vu que tu es sur ce forum à refaire le monde avec nous, je pense que tu vois ce que ça implique au contraire.
Ce que ça implique, c'est le "je suis le plus fort donc j'ai raison, même quand j'ai tort"
"Il y a un problème? Ba, si je pouvais y faire quelque chose, je l'aurais fait, puisque je suis le plus fort..."

@Wam: fais attention, tu commence à devenir extrémiste, ou clair-voyant, je ne sais pas, mais ça me fait peur. Retourne dans le rang, vite!

109 · Le 14/02/2006, à 01:38

@mars : je ne suis pas d'accord, il est impossible de créer le système de paquets ultime, s'il en existe plusieurs c'est que les goûts sont différents, il est strictement impossible de créer un "dépôt global" (entre la rigueur Slackware qui n'inclut pas les dépendances, la facilité des RPM, la gestion des dépendances des DEB, l'optimisation des paquets sources, le soin plus ou moins grand apporté à la stabilité, à la sécurité, à la rapidité ou à la liberté du logiciel empaqueté selon les distribs...).

@wam : les distribs bureautiques Linux ont quand même assez en commun pour ne pas nécessiter un jeu complet de librairies pour chaque distrib. Il y a des paquets comme la libc, zlib ou Xorg qui sont présents partout.
Donc un système incluant toutes les librairies nécessaires au fonctionnement du programme directement dans le paquet permet de faire fonctionner celui-ci sur cette base commune aux distros, sans se soucier des différences. Bien sûr, cela prend plus de mémoire (inclure les kdelibs pour une application KDE qui est susceptible de tourner sur un système utilisant Gnome ou WindowMaker, par exemple), et est moins sécurisé (en cas de faille de sécurité il faut mettre à jour tous les programmes utilisant la librairie incriminée). Voilà pourquoi c'est quelque chose qui ne convient pas aux serveurs ou au système de base.
Ce que tu proposes, ce n'est rien d'autre que ce qui existe déjà (une version pour chaque système, malheureusement c'est très limité).

L'avantage est pourtant énorme. Imaginons un monde parfait où toutes les distros grand public, par exemple, sont compatibles avec la norme LSB. Disons que tout logiciel desktop qui se respecte propose une version .rpm standard sur son site, et qu'elle existe en statique histoire de ne pas se casser la tête avec les dépendances (il y a un paquet lsb-rpm dans les dépôts qui permet de créer ces paquets, j'imagine que ça ne doit pas être trop sorcier). Disons que lorsqu'on télécharge un tel fichier sur son Ubuntu, qu'on clique sur le .rpm, une jolie fenêtre se lance en disant : "nous allons à présent installer le logiciel sur votre ordinateur" et demande le mot de passe root. En arrière-plan, alien s'occupe de convertir le rpm en deb, dpkg s'occupe de l'installer/mettre à jour et de l'inscrire dans la base de données, freedesktop s'occupe de l'afficher dans le menu. Et ce pour quasiment 100% des applications. C'est pas beau ça (même si c'est loin d'être parfait) ?

Pour résumer ce que je trouve important c'est la possibilité d'inclure les dépendances et la possibilité de mettre à jour, ainsi que le fait que ce genre de paquet devrait être proposé par l'équipe de développement du programme elle-même sur le site officiel.

wam · Le 14/02/2006, à 01:52

Ne te méprends pas, je suis tout à fait d'accord avec toi. Je suis le premier à m'émerveiller du concept d'autopackage.
Je remarque juste que ça peut potentiellement créer un problème d'inertie énorme (bon d'accord, 1% des ordinateurs, c'est pas énorme) si quelqu'un vient un jour avec une idée révolutionnaire.

109 · Le 14/02/2006, à 02:37

wam a écrit :

Je remarque juste que ça peut potentiellement créer un problème d'inertie énorme.

Il n'y a qu'à voir la polémique créée autour du système de PBI utilisé par PC-BSD (installation en cliquant dessus, intégration des dépendances, gestion des mises à jour...), comme quoi c'est pas centralisé, c'est pas sécurisé, ça multiplie les librairies, etc etc, ça dérange l'ordre établi par les "anciens" en recherchant la convivialité plutôt que l'efficacité technique.

N'empêche qu'avec un système comme ça, on pourrait avoir Firefox 1.5 sur Breezy sans devoir faire des acrobaties ou modifier 40 autres paquets (je sais que pour des raions de sécurité et de stabilité de la base en entreprise le système est plus ou moins "figé", mais en tant qu'utilisateur on devrait avoir le choix) Je vois bien une intégration dans la base de données des paquets d'Ubuntu, avec un suffixe au nom du genre"firefox-local". Et lors de la mise à jour vers Dapper le paquet "firefox" officiel remplace "firefox-local" ***rêve***

severino · Le 22/02/2006, à 16:50

++

Alors, on pétitionne pour klik ou pour zero-install par défaut dans l'après-prochaine Ubuntu ?
http://dot.kde.org/1126867980/1126955369/

En attendant, ce qui manque le plus, c'est davantage de logiciel dans les dépôts. Faudrait apprendre à contribuer à PLF... :-) Je m'y perd encore avec les histoires de dépôts :-(

Mais l'un n'empêche pas l'autre ;-)

C'est vrai qu'en attendant à chaque fois la prochaine version d'Ubuntu et son lot de nouveauté, mieux vaudrait klik que des backports. S'il y avait eu par exemple des klik pour firefox 1.5, et Klik installé par défaut sur Ubuntu, ça l'aurait fait.

Pour commencer, toujours en attendant, il pourrait y avoir un tutorial clair et universel pour apprendre à installer proprement un tar.gz sur son /home/monlogin/app/. Pour faciliter, il faudrait avoir plus souvent des .tar.gz avec librairie statique (intégrée). Est-ce réaliste ?

wam · Le 22/02/2006, à 17:14

si on demande à tout le monde de compiler ses paquage, je crois qu'on s'éloigne un peu du postulat Ubuntu initial, niveau simplicité... Franchement, avoir des logiciels à jour, je m'en fous, du moment que mon ordi est stable. Je ne vois pas de différence entre une version et une autre et je peux bien attendre 3 mois qu'il soit dispo. Pour ête "on the edge", il y a debian unstable

109 · Le 22/02/2006, à 18:58

wam a écrit :

je peux bien attendre 3 mois qu'il soit dispo

Dans l'absolu je suis d'accord, mais en pratique ce n'est pas toujours facile. Attendre jusqu'à avril des logiciels comme Firefox 1.5 c'est lourd, alors que les extensions se généralisent sur cette version sans être toujours disponibles pour la 1.0.7. Si on ne voit que peu la différence, pas de problème. Lorsqu'elle est flagrante, on ronge son frein

Pirrote · Le 22/02/2006, à 19:04

Bonjour,
je pense aussi que la diversité est bonne toutefois, j'avoue que j'apprecierai que synaptic puisse installer aussi bien des .deb que des .rpm.

Ceci car je constate que la plupart des logiciels ou pilotes sont dispo en .rpm et m'y connaissant que trop peut j'ai du mal à m'aventurer dans l'install de . rpm avec alien, puis recompilation du noyau, machin bidulle truc etc...

Ainsi il serait pratique que synaptic puisse installe tous seul les .rpm en gernerant tous seul les .deb grace à alien, pour l'utilisateur sa serait transparent donc facile. Je sais cela peut faire prendre des risque mais s'il y a des soluce autre...

Mickael

severino · Le 27/02/2006, à 22:50

j'avoue que j'apprecierai que synaptic puisse installer aussi bien des .deb que des .rpm.

Jamais !

wam · Le 27/02/2006, à 23:52

jamais quoi? ça sera jamais possible ou ça te ferait mal?

severino · Le 01/03/2006, à 22:44

Ca me ferait mal.
:-p

Et ce ne sera pas nécessaire, à mon avis, si Ubuntu continue sur sa lancée.

Par contre le système de KLIK me convient : c'est parfait pour tester les nouvelles versions qui ne sont pas encore intégrée.

Et plus de bons tutoriaux pour commencer à compiler, puis à créer des .deb, puis à les mettre dans universe ou plf...

Dernière modification par severino (Le 01/03/2006, à 22:49)

Pirrote · Le 02/03/2006, à 14:17

Je trouve ta réaction assez tranchée, Ok je suis d'accord que c'est important le .deb mais etant depuis peu sous linux j'ai constater d'une chose tous les logiciels ne sont pas dans synaptic (et encore moins en .deb) alors il te reste la solution d'aller sur le site et la que trouve tu des .rpm. destine à linux.

Ubuntu se doit etre simple d'utilisation est je pense que le "commun des mortel" souhaite installer un logiciel pour linux sans se poser la question "est ce que c'est compatible avec ma distrib".

Si je dis cela c'est que j'ai installe ubuntu à ma mere (je n'habite pas avec elle). et je constate des difficultés qu'elle rencontre et qui pourrait si elle ne souhaitai pas comprendre et apprendre linux, le faire retourner chez win

Enfin ce que j'en dis n'est peut etre qu'un avis isolé et nous devons tous travailler dans un meme sens....

Mickael

wam · Le 02/03/2006, à 14:26

des difficultés qui viendraient du format des paquets? j´aimerais bien savoir lesquelles... Tu essaie d´installer des paquets en .exe?

alien -d paquet.rpm

pour transformer la plupart des rpm en deb

Pirrote · Le 02/03/2006, à 14:34

J'suis d'accord moi je le sais, mais je te rappelle que je parle d'un utilisateur lambda telle que ma mere

Et donc je trouve que cette ligne de commande pour se faire de façon transparente via synaptic par exemple

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 13/02/2006, à 20:22

Vers l'idéal d'un système de paquets universels

#2 Le 13/02/2006, à 20:27

Re : Vers l'idéal d'un système de paquets universels

#3 Le 13/02/2006, à 20:29

Re : Vers l'idéal d'un système de paquets universels

#4 Le 13/02/2006, à 20:32

Re : Vers l'idéal d'un système de paquets universels

#5 Le 13/02/2006, à 20:38

Re : Vers l'idéal d'un système de paquets universels

#6 Le 13/02/2006, à 20:42

Re : Vers l'idéal d'un système de paquets universels

#7 Le 13/02/2006, à 20:44

Re : Vers l'idéal d'un système de paquets universels

#8 Le 13/02/2006, à 20:50

Re : Vers l'idéal d'un système de paquets universels

#9 Le 13/02/2006, à 23:32

Re : Vers l'idéal d'un système de paquets universels

#10 Le 13/02/2006, à 23:33

Re : Vers l'idéal d'un système de paquets universels

#11 Le 14/02/2006, à 00:50

Re : Vers l'idéal d'un système de paquets universels

#12 Le 14/02/2006, à 01:01

Re : Vers l'idéal d'un système de paquets universels

#13 Le 14/02/2006, à 01:38

Re : Vers l'idéal d'un système de paquets universels

#14 Le 14/02/2006, à 01:52

Re : Vers l'idéal d'un système de paquets universels

#15 Le 14/02/2006, à 02:37

Re : Vers l'idéal d'un système de paquets universels

#16 Le 22/02/2006, à 16:50

Re : Vers l'idéal d'un système de paquets universels

#17 Le 22/02/2006, à 17:14

Re : Vers l'idéal d'un système de paquets universels

#18 Le 22/02/2006, à 18:58

Re : Vers l'idéal d'un système de paquets universels

#19 Le 22/02/2006, à 19:04

Re : Vers l'idéal d'un système de paquets universels

#20 Le 27/02/2006, à 22:50

Re : Vers l'idéal d'un système de paquets universels

#21 Le 27/02/2006, à 23:52

Re : Vers l'idéal d'un système de paquets universels

#22 Le 01/03/2006, à 22:44

Re : Vers l'idéal d'un système de paquets universels

#23 Le 02/03/2006, à 14:17

Re : Vers l'idéal d'un système de paquets universels

#24 Le 02/03/2006, à 14:26

Re : Vers l'idéal d'un système de paquets universels

#25 Le 02/03/2006, à 14:34

Re : Vers l'idéal d'un système de paquets universels

Pied de page des forums