Aujourd'hui, j'ai le plaisir de vous annoncer que des mois de travail portent enfin leurs fruits. Après un début purement théorique, le gestionnaire de paquets que je développe pour le moment sort enfin à la lumière du soleil.
Cette version n'est pas du tout stable, et n'est là que pour montrer que le travail avance, mais peut déjà être testée, et appréciée. Certaines fonctionnalités critiques sont encore absentes (désinstallation, mise à jour), mais l'installation marche déjà correctement.
Qu'est-ce que Setup ?
Setup est le gestionnaire de paquets développé par le Projet Logram, dans le but de prouver qu'un gestionnaire de paquet peut être léger, puissant et rapide. Il sera en outre utilisé par notre future distribution.
Le but de Setup n'est pas d'être hyper puissant comme le sont APT ou Yum, mais bien de convenir à un usage de tous les jours sur des ordinateurs de bureau. La sécurité n'est pas en reste, mais certaines fonctionnalités lourdes ne sont pas prévues. En outre, un accent est mis sur la rapidité, voir «l'instantanéibilité» des actions possibles (bench en fin de journal)
Pourquoi ne pas reprendre RPM/Deb/Pacman/etc ?
La question a déjà été posée maintes et maintes fois. Le principal avantage de la création d'un nouveau gestionnaire de paquets est de pouvoir apprendre des erreurs des autres, sans devoir maintenir une compatibilité avec l'existant. Setup est une base solide sur laquelle on peut construire plein de choses, et est amené à devenir pas mal du tout.
Des «monstres» comme RPM ou DPKG/APT sont difficilement maintenables de par le fait qu'ils sont découpés en plein d'outils. Il existe plusieurs forks de RPM, et DPKG peut s'utiliser avec apt-get, aptitude ou dselect. Tout ceci fait qu'un bug trouvé dans un des outils doit être corrigé dans les autres. Créer un paquet RPM ou Deb est également complexe, alors qu'en créer un pour Setup est un jeu d'enfant.
De plus, un très mauvais point pour ces outils est que la partie «résolution des dépendances» est séparée de la partie «gestion des paquets». RPM peut être utilisé avec URPMI, yum, Zypper, voire apt-rpm. DPKG est utilisé par aptitude, apt-get ou dselect. Ceci empêche certaines goodies, très utilisées par Setup, comme le téléchargement et l'installation en parallèle, ainsi qu'un contrôle poussé de l'installation des paquets.
Quand aux gestionnaires de paquets comme Pacman et autres, ils sont très biens, et Setup s'en inspire. Ils ne semblent pas avoir les mêmes problèmes que les gestionnaires de paquets comme RPM, mais manquent parfois de quelques fonctionnalités, ou de rapidité. Un paquet ne peut par exemple pas «poser de questions» (DebConf-like) avec Pacman, ou alors ce n'est pas utilisé.
Pourquoi utiliser Setup, qu'a-t-il de mieux ?
Setup a un énorme avantage sur les autres : il est rapide, très rapide. La recherche d'un paquet, parmis 25 000, est instantané. La résolution des dépendances est inmesurable à l'échelle humaine, de même que toutes les autres opérations. Même la mise à jour de la base de donnée binaire, une opération extrêmement complexe (lecture de fichiers texte de 20 Mio, pré-résolution des dépendances, écriture binaire optimisée), ne prend qu'à peine plus de 2 secondes pour le contenu de Debian Testing, section main.
Setup est aussi une petite base de code simple et documentée (pour le moment en français, je fais trop de fautes d'anglais et personne n'a encore traduit mes commentaires). La gestion des paquets elle-même tient dans moins de 5500 lignes, le front-end en ligne de commande fait à peine plus de 1500 lignes. Le code lui-même est du C++ correctement organisé et utilisant Qt (question débattue plus loin).
Setup, bien que largement moins puissant que les autres gestionnaire de paquets, permet d'apprendre comment un programme de ce type fonctionne, et comment ça se crée. Setup est tout jeune, sa première ébauche datant du mois de septembre.
Utiliser Qt ? Quelle horreur !
Ce commentaire (ok, un peu moins sec), a été fait dans un précédent journal parlant de Setup. La raison évoquée était que dépendre de Qt pour «un programme de si bas niveau» est une aberration, surtout pour un serveur.
Plusieurs raisons font que Qt est utilisé, les voici :
- Logram n'est absolument pas destiné aux serveurs. Là-dessus, mettez une Debian ou une RedHat. Setup suit ce mouvement et ignore totalement ce milieu. Le serveur, c'est ok. C'est sur le desktop que Linux doit faire ses preuves. (note: je ne prétend nullement apporter quoique ce soit de spécial dans ce domaine, j'essaie, c'est tout)
- Qt est découpée en bibliothèques. Nous ne dépendons pas, pour le front-end console et la bibliothèque, de QtGui (la plus grosse partie de Qt, se chargeant de la GUI). Les seuls bibliothèques de Qt utilisées sont QtCore, QtXml, QtScript et QtNetwork.
- Qt est une dépendance «légère» par rapport à d'autres gestionnaires de paquet dont on se plaint bien moins. URPMI dépend de Perl, Portage est écrit en Python, etc. Ok, il y a bien RPM et la suite DEB qui sont en C, mais le C++ n'est pas plus lourd.
- Qt facilite énormément de choses. C'est une bibliothèque Libre (je le rappelle pour ceux qui sont trois guerres en retard) qui fournit énormément de code prêt à l'emploi. La gestion des téléchargements, des processus, du XML, des communications asynchrones, des tables de hash et des listes est gérée par Qt, gratuitement, ce qui permet de limiter les bugs au minimum.
- Qt est différent de KDE. Ce n'est pas parce que Setup dépend de Qt qu'il dépend de KDE, loin de là !
- Les performances ne sont absolument pas réduites, voir la suite. De plus, les éventuelles parties trop lentes en Qt sont remplacées par du C++ STL, comme par exemple la gestion des fichiers (un fichier texte de 20Mio, c'est un peu trop pour Qt). On n'est pas obligé de faire du 100% Qt, on peut prendre ce qu'on veut, et optimiser le reste
Les performances de Setup
Voici une suite de commandes avec leur résultat et le temps qu'elles prennent, le tout mesuré sur un ordinateur d'age moyen composé d'un AMD Athlon 64 X2 4000+ (2,4Ghz) et de 2Gio de RAM. Cette machine est certes assez puissante, mais ça va. La quantité de RAM importe peu, Setup étant très léger sur cet aspect (l'opération la plus lourde, lancée dans Valgrind, ne prend que 50Mio. Sans Valgrind, 35Mio à peu près sont utilisés, mais c'est difficile à mesurer tant Setup est rapide).
Attention, cette partie est un peu longue, Setup pouvant afficher pas mal de choses.
1. Mise à jour de la base de donnée binaire
Un dépot local, contenant les 28101 de la future Ubuntu LTS, portés grâce à un script Python maison, est importé dans la base de donnée binaire comme suit :
$ time ./setup -R /tmp/setup update
[0/6] Téléchargement de /home/steckdenis/repo/dists/experimental/x86_64/packages.lzma
gpg: Signature faite le mer 25 nov 2009 13:41:39 CET avec la clé RSA ID 47798B4B
gpg: Bonne signature de « Logram Repository »
[1/6] Téléchargement de /home/steckdenis/repo/dists/experimental/x86_64/translate.fr.lzma
gpg: Signature faite le mer 25 nov 2009 13:41:39 CET avec la clé RSA ID 47798B4B
gpg: Bonne signature de « Logram Repository »
[2/6] Téléchargement de /home/steckdenis/repo/dists/experimental/all/packages.lzma
gpg: Signature faite le mer 25 nov 2009 13:41:39 CET avec la clé RSA ID 47798B4B
gpg: Bonne signature de « Logram Repository »
[3/6] Téléchargement de /home/steckdenis/repo/dists/experimental/all/translate.fr.lzma
gpg: Signature faite le mer 25 nov 2009 13:41:39 CET avec la clé RSA ID 47798B4B
gpg: Bonne signature de « Logram Repository »
[4/6] Téléchargement de /home/steckdenis/repo/dists/ubuntu/x86_64/packages.lzma
gpg: Signature faite le dim 22 nov 2009 13:57:46 CET avec la clé RSA ID 47798B4B
gpg: Bonne signature de « Logram Repository »
[5/6] Téléchargement de /home/steckdenis/repo/dists/ubuntu/x86_64/translate.fr.lzma
gpg: Signature faite le sam 21 nov 2009 10:06:48 CET avec la clé RSA ID 47798B4B
gpg: Bonne signature de « Logram Repository »
[0/6] Mise à jour de la base de donnée : Lecture des listes
[1/6] Mise à jour de la base de donnée : Génération de la liste des paquets
[2/6] Mise à jour de la base de donnée : Écriture des chaînes de caractère
[3/6] Mise à jour de la base de donnée : Écriture des traductions
[4/6] Mise à jour de la base de donnée : Enregistrement des dépendances
[5/6] Mise à jour de la base de donnée : Enregistrement de données supplémentaires
real 0m2.406s
user 0m1.954s
sys 0m0.298s
C'est le traitement le plus lourd, équivalent de «apt-get update». Pas spécialement plus rapide que le reste, mais déjà pas mal, surtout que cette lenteur fait gagner beaucoup plus tard.
2. Recherche de paquets
Maintenant, affichons tous les paquets. C'est un autre traitement particulièrement lourd, nécessitant l'instanciation de 28 000 classes. La mémoire et le cache sont clairement ici le goulot d'étranglement :
$ time ./setup -R /tmp/setup search '*' | wc -l
28105
real 0m3.072s
user 0m2.795s
sys 0m0.249s
Heureusement, une recherche normale ne prend que quelques centièmes de secondes (équivalent de «apt-cache search») :
$ time ./setup -R /tmp/setup search galeon
galeon 2.0.7-1ubuntu2 GNOME web browser for advanced users
galeon-common 2.0.7-1ubuntu2 data for the galeon web browser
real 0m0.076s
user 0m0.055s
sys 0m0.007s
C'est agréable à utiliser, je peux vous le dire. Si tous les autres gestionnaires de paquets faisaient autant !
3. Métadonnées
Testons maintenant la rapidité avec laquelle Setup peut afficher des informations sur un paquet, l'équivalent de «apt-cache showpkg». Le "-C" permet d'afficher également le changelog. Pour réduire les délais ne provenant pas de Setup, un dépôt local est utilisé, pour ne pas devoir télécharger les métadonnées :
$ time ./setup -R /tmp/setup -C showpkg initng
Nom : initng
Version : 0.6.99+git20091106~1
Titre : Système de démarrage Init-ng
Logiciel graphique : Oui
Section : base
Distribution : experimental
Status : Non-installé
Téléchargement : 190 Kio
Taille installée : 420 Kio
Dépôt d'origine : repo
Paquet source : initng
Licence : GPL
Mainteneur : steckdenis
Description courte : Système de démarrage init-ng, remplaçant de SysVInit
Description longue :
Initng est un nouveau système de démarrage corrigeant les différents problèmes du vieilissant SysVInit. Entre autres, il permet de démarrer les services en parallèle, ce qui peut drastiquement réduire le temps de démarrage (si un processus attend 4 secondes avant de faire quelque-chose, un autre peut déjà travailler).
Initng permet également une personnalisation du démarrage plus poussée, et une plus grande légèreté. Ses fichiers de configuration sont facilement éditables, et Logram propose un outil pour le gérer.
Dépendances :
Légende : D: Dépend S: Suggère C: Conflit P: Fourni R: Remplace N: Est requis par
D: libinitng (= 0.6.99+git20091106~1)
N: initng-plugins (= 0.6.99+git20091106~1)
Versions disponibles :
Légende : * = Disponible, I = installée, R = supprimée
* 0.6.99+git20091106~1 Système de démarrage init-ng, remplaçant de SysVInit
Historique des versions :
0.6.99+git20091106~1 (steckdenis), 14/11/09 00:00
Ajout des questions
0.6.99+git20091106~1 (steckdenis), 9/11/09 00:00
Ajout des informations des fichiers qui doivent aller dans __LOGRAM
0.6.99+gitNov62009~1 (steckdenis), 23/10/09 00:00
Modification du changelog
0.6.99+gitSep202009~1 (steckdenis), 17/10/09 00:00
Première version
real 0m0.058s
user 0m0.008s
sys 0m0.010s
4. Solveur de dépendances
Maintenant, testons la rapidité du solveur, d'abord sur une petite requête, puis sur une grosse installation :
$ time ./setup -R /tmp/setup add initng-plugins
Paquets qui seront installés ou supprimés :
Légende : I: Installer R: Supprimer U: Mettre à jour P: Supprimer totalement
I: initng-plugins 0.6.99+git20091 Système de démarrage init-ng, modules supplémentaires
I: initng 0.6.99+git20091 Système de démarrage init-ng, remplaçant de SysVInit
I: libinitng 0.6.99+git20091 Système de démarrage init-ng, bibliothèques partagées
Solution 1 sur 1, de poids 0. Téléchargement de 279 Kio, installation de 910 Kio
Accepter (y), Suivante (n), Précédante (p) ou Annuler (c) ?
real 0m0.038s
user 0m0.015s
sys 0m0.011s
Pas mal, je connais des gestionnaires de paquets qui font pire. Voici maintenant une résolution bien plus complexe, utilisant les paquets Ubuntu :
$ time ./setup -R /tmp/setup -S off add vim
Paquets qui seront installés ou supprimés :
Légende : I: Installer R: Supprimer U: Mettre à jour P: Supprimer totalement
I: vim 7.2.245-2ubuntu Vi IMproved - enhanced vi editor
I: vim-common 7.2.245-2ubuntu Vi IMproved - Common files
I: libc6 2.10.1-3ubuntu1 GNU C Library:Shared libraries
I: libc-bin 2.10.1-3ubuntu1 GNU C Library:Binaries
I: libgcc1 4.4.2-2ubuntu1 GCC support library
I: gcc-4.4-base 4.4.2-2ubuntu1 The GNU Compiler Collection (base package)
I: tzdata 2009r-1ubuntu1 time zone and daylight-saving time data
I: debconf 1.5.28ubuntu1 Debian configuration management system
I: debconf-i18n 1.5.28ubuntu1 full internationalization support for debconf
I: liblocale-gette 1.05-4build1 Using libc functions for internationalization in Perl
I: libtext-iconv-p 1.7-2 converts between character sets in Perl
I: perl-base 5.10.0-24ubuntu minimal Perl system
I: libtext-wrapi18 0.06-7 internationalized substitute of Text::Wrap
I: libtext-charwid 0.04-6 get display widths of characters on the terminal
I: findutils 4.4.2-1 utilities for finding files--find, xargs
I: vim-runtime 7.2.245-2ubuntu Vi IMproved - Runtime files
I: dpkg 1.15.4.1ubuntu1 Debian package management system
I: libacl1 2.2.48-1 Access control list shared library
I: libattr1 2.4.44-1 Extended attribute shared library
I: libgpm2 1.20.4-3.2ubunt General Purpose Mouse - shared library
I: libncurses5 5.7+20090803-2u shared libraries for terminal handling
I: libpython2.6 2.6.4-1ubuntu1 Shared Python runtime library (version 2.6)
I: python2.6 2.6.4-1ubuntu1 An interactive high-level object-oriented language (version 2.6)
I: python2.6-minim 2.6.4-1ubuntu1 A minimal subset of the Python language (version 2.6)
I: libssl0.9.8 0.9.8g-16ubuntu SSL shared libraries
I: zlib1g 1.2.3.3.dfsg-15 compression library - runtime
I: mime-support 3.46-1ubuntu1 MIME files 'mime.types' & 'mailcap', and support programs
I: libbz2-1.0 1.0.5-3 high-quality block-sorting file compressor library - runtime
I: libdb4.7 4.7.25-7ubuntu2 Berkeley v4.7 Database Libraries [runtime]
I: libncursesw5 5.7+20090803-2u shared libraries for terminal handling (wide character support)
I: libreadline6 6.0-5 GNU readline and history libraries, run-time libraries
I: readline-common 6.0-5 GNU readline and history libraries, common files
I: libsqlite3-0 3.6.16-1ubuntu1 SQLite 3 shared library
I: libselinux1 2.0.88-1 SELinux runtime shared libraries
Solution 1 sur 1, de poids 0. Téléchargement de 23 Mio, installation de 83 Mio
Accepter (y), Suivante (n), Précédante (p) ou Annuler (c) ?
real 0m0.037s
user 0m0.017s
sys 0m0.010s
Installer des paquets avec plus de dépendances est normalement possible, mais le script de portage Ubuntu vers Setup laisse quelques imperfections (des paquets qui n'existent pas par exemple, ou des conflits étranges). Cette résolution des dépendances montre l'exactitude des solutions trouvées (ce n'est pas loufoque), et la rapidité. 37 centièmes de seconde, c'est très rapide !
5. Installation
L'installation en elle-même est rapide, mais difficile à démontrer pour les raisons suivantes :
- Les paquets Ubuntu ne peuvent être installés par Setup. Ce «port» n'est qu'un hack immonde visant à tester le solveur.
- Les paquets que j'ai créés sont des paquets de tests, posant des «questions» (comme DebConf). Déduire mon temps de réaction serait trop imprécis pour obtenir une mesure fiable
La seule solution est d'installer le seul paquet qui appartient à Logram et ne pose pas de questions : libinitng. Pour avoir tout de même une résolution des dépendances, libinitng-dev (qui dépend de libinitng) sera installé également. Il ne pose pas non-plus de questions.
$ time ./setup -R /tmp/setup add libinitng-dev
Paquets qui seront installés ou supprimés :
Légende : I: Installer R: Supprimer U: Mettre à jour P: Supprimer totalement
I: libinitng-dev 0.6.99+git20091 Système de démarrage init-ng, fichiers de développement
I: libinitng 0.6.99+git20091 Système de démarrage init-ng, bibliothèques partagées
Solution 1 sur 1, de poids 0. Téléchargement de 168 Kio, installation de 400 Kio
Accepter (y), Suivante (n), Précédante (p) ou Annuler (c) ?
Installation des paquets...
[0/2] Téléchargement de libinitng-dev
[1/2] Téléchargement de libinitng
[0/2] Installation de libinitng-dev
[1/2] Installation de libinitng
Paquets installés !
real 0m0.139s
user 0m0.058s
sys 0m0.086s
Vous voyez que les téléchargements et les installations sont faits en parallèle. Ainsi, pas de temps perdus (les téléchargements peuvent être sur plusieurs mirroirs, si jamais il y en a un qui est lent. Les installations peuvent utiliser plusieurs coeurs). Le tout est très rapide, et marche. Les fichiers sont installés dans /tmp/setup, pour éviter de sâlir la distribution hôte.
6. Fichiers d'un paquet installé
On peut ensuite récupérer la liste des fichiers installés par un paquet :
$ time ./setup -R /tmp/setup files libinitng-dev
/tmp/setup/usr/share/doc/initng/initng-chart.png
... Je vous fais grâce des 100 lignes ici ...
/tmp/setup/usr/include/libinitng-0.7/initng/event/all.h
/tmp/setup/usr/include/libinitng-0.7/initng.h
real 0m0.012s
user 0m0.005s
sys 0m0.004s
Conclusion
J'espère que lire ce journal ne vous a pas trop ennuyé. Je ne pense pas qu'une dépêche soit nécessaire, du fait que ce n'est que la sortie d'une version Alpha d'un programme peu connu. J'espère que vous trouverez un intérêt à Setup. Pour plus d'informations, lisez l'annonce officielle de la sortie, avec des détails moins techniques mais plus logistiques (et aussi une grosse simplification des choses pour être compréhensible par plus de monde).
Merci de m'avoir lu.
PS: Ce journal s'adresse avant tout à ceux qui s'intéressent à Setup, et je sais qu'il y en a (ils se sont manifestés dans les autres news). Il n'a pas pour but de me vanter, de vanter Setup, de faire de la pub, etc. J'autorise tout le monde à m'ignorer royalement :-) .
# Interessant
Posté par Tof . Évalué à 10.
Bravo ! Et bonne continuation.
[^] # Re: Interessant
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: Interessant
Posté par tuXico . Évalué à 2.
# pas d'accord
Posté par zecrazytux (site web personnel) . Évalué à 10.
apparemment t'as aucune automatisation / pas de framework de packaging, juste un bête template puisque tu appelles des fonctions définis dans un script shell.
Le choix des conventions (__LOGRAM par exemple) me parait complètement non ergonomique / logique / pratique.
Utiliser du XML pour la description du package, ça va pas aider la création de package. C'est peut être plus facile pour toi à parser avec la lib Qtquivabien, mais imho c'est pas un avantage pour le packager.
En fait j'aimerais que tu argumente sur la complexité de création de packages RPM ou DEB et la simplicité des packages Setup. Là tu nous sort un avantage tout beau tout shiny, sans argument.
De toute façon le packaging ça sera toujours complexe, ça demandera toujours du temps et des hacks. Même si c'est cool et qu'en 4 fonctions shell t'as lancé tes make/make install sur vim et que ça marche bien, tu verra qu'au final ta simplicité apparente se transformera en un truc plus complexe et inmaintenable que les framework de packaging type debian (debhelper, cdbs...) ou pkgsrc.
Comme beaucoup je suis assez stupéfait par ta"productivité": on entends parler de tes nouveautés régulièrement, ça avance :)
Mais j'attends de voir ce que ça donne... Je ne suis pas convaincu
Si quelques packagers pouvaient donner des avis éclairés là dessus, ça m'intéresserait bien, pour comparer à ma maigre expérience de packaging rpm/deb/pkgsrc.
Sinon, bonne continuation, t'as l'air de bien t'amuser ;) c'est l'essentiel
[^] # Re: pas d'accord
Posté par houra . Évalué à 2.
De quoi parle-t-on ?
On parle :
- D'un logiciel dont le rôle est de lire et transmettre des données de type chaîne de caractère
- D'établir des liens entre ces données ( algo de résolutions des dépendances )
-Et à partir de là, d'établir une chaîne de logiciels à installer, désinstaller, mettre à jour. ( algo d'installation et désinstallation )
Pour ta remarque sur l'absence de Framework de création de paquet, je pense que n'importe quel RAD dispose de quoi fabriquer un bouton " creer paquet SETUP " permettant de remplir des champs composés de contenus de noeuds XML. Donc, ça, ça devrait être 8 heures de boulot sans aucun problème, sur la base du contenu du fichier XML présenté.
Donc pour ce plugin de création de paquets SETUP, personnellement je considère que l'affaire est déjà réglée. ( faut pas sous estimer le temps pour le réaliser et le tester, bien sûr , mais c'est loin d'être rédhibitoire .
Pour la " productivité ", j'ai l'impression que personne n'a compris le fonctionnement :
Alors qu'un logiciel de gestion des logiciels traditionnel fonctionne la plupart du temps en relation avec une BDD, que presque tout se passe dans les requêtes SQL et dans les jointures des tables ( j'exagère, je n'ai aucune idée de la façon dont fonctionne RPMDrake ) , ici, SteckDenis nous propose une vision fondamentalement beaucoup plus réfléchie.
En constatant _ et c'est une réalité _ la lourdeur de réaction du fonctionnement direct au dessus d'un SQLite ou autre, il nous propose de ( je traduis pour ceux qui n'auraient pas pigé ) _ Charger en mémoire vive ( RAM ) beaucoup plus rapide pour la manipulation de grandes quantités de données , toutes les info permettant de :
- connaitre le nom et la version du logiciel
- connaitre les bibliothèques ( libraries ) qui en dépendent.
- pointer vers les adresses des paquets dans la base de donnée.
L'utilisation de la RAM, c'est beaucoup, beaucoup plus rapide que les utilisations par table SQL et fichiers XML.
C'est quelques centièmes à quelques dixièmes de secondes en C pour lire un fichier d'1 Mo par exemple . Je suppose qu'en C++, ça va être un peu plus lent, mais c'est rien comparé à la lecture de la même quantité de données dans une table SQL !
A la suite de ce chargement, le logiciel ( SETUP ) va pouvoir réaliser tous les traitements algorithmiques que vous voulez.
Une fois décidé quels logiciels doivent être installés/désinstallés/mis à jour, le logiciel peut alors réaliser un _post_traitement _ très rapidement :
La vérification de la non imbrication d'un certain nombre de logiciels permettant de réaliser une installation parrallélisée. ( un peu grillé par FreeBSD-8.0 sur ce coup-là :) ).
Il est évident que ce genre de travail aura des répercussions sur tous les gestionnaires de paquets du monde . Et ça, c'est bien. ( surtout si c'est libre ).
Steckdenis, franchement, continue, ça fait plaisir de voir des gens qui se défoncent , surtout ici .
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: pas d'accord
Posté par beagf (site web personnel) . Évalué à 10.
Comme tu dis, tu n'a aucune idée de la manière dont ça fonctione et ça ce voit... ;-)
Des gestionnaire de paquets qui utilise SQLlite out une autre base de données SQL, il y en a pas de masses.
La majoritée du temps c'est un format interne tout simplement parce que la gestions de dépendances qui est l'opération la plus complexe qu'ils aient à réaliser ne ce fait pas à coup de jointure mais plutot à coup de solveur SAT pour les plus bourrins.
En constatant _ et c'est une réalité _ la lourdeur de réaction du fonctionnement direct au dessus d'un SQLite ou autre, il nous propose de ( je traduis pour ceux qui n'auraient pas pigé ) _ Charger en mémoire vive ( RAM ) beaucoup plus rapide pour la manipulation de grandes quantités de données , [...]
L'utilisation de la RAM, c'est beaucoup, beaucoup plus rapide que les utilisations par table SQL et fichiers XML.
Même s'il n'y a pas de SQL ou autre dans les gestionnaire de paquets, ce que tu dis reste faux. On est ici sur des données qui font quelques dizaine de Mo, et même en imaginant une base de donnée très lourde qui à un surcout de 50% ça reste sans problème chargeable en mémoire. Je serais surpris que n'importe quelle base de donnée ne charge pas une telle base en mémoire éventuellement de manière indirecte par un mmap.
L'utilisation de la RAM, c'est beaucoup, beaucoup plus rapide que les utilisations par table SQL et fichiers XML.
Deux chose qui n'on absolument rien à voir : le chargement en RAM c'est juste l'endroit ou tes données sont stockée, l'utilisation de SQL ou d'XML c'est la mnière dont tu les stocke à cet endroit. Tu peut stocker du SQL ou du XML en RAM sans problème. (heureusement d'ailleur...)
Et pour ce qui est du surcout éventuel du SQL, il faut bien voir que les bases de données sont optimisées avec éventuellement des index pour accélérer au maximum toutes es opérations de recherche, donc le surcout, il n'éxiste pas vraiment, bien au contraire.
C'est quelques centièmes à quelques dixièmes de secondes en C pour lire un fichier d'1 Mo par exemple . Je suppose qu'en C++, ça va être un peu plus lent, mais c'est rien comparé à la lecture de la même quantité de données dans une table SQL !
C'est un peut hors sujet, mais que tu le fasse en C ou en C++ ça prend le même temps... la meilleur manière de charger ton fichier en mémoire c'est de faire un mmap...
Une table SQL mapper c'est en général juste un mmap pour la charger en mémoire, enfin pas tout à fat charger, juste mapper et elle est chargée à la demande. La strucuture est dans le fichier mapper pas besoin de la reconstruire. Si tu as rééllement besoin de relire tout le fichier explicitement plutot que par un mappage c'est que tu est obliger de reconstruire la structure et donc c'est bien plus lent. Donc soit c'est égalitée, soit c'est SQL qui gagne...
A la suite de ce chargement, le logiciel ( SETUP ) va pouvoir réaliser tous les traitements algorithmiques que vous voulez.
C'est la que le SQL perd car la gestion des dépendances est un problème qui n'est pas adapté à SQL et c'est pour cela que à peu près aucun gestionnaire de paquetages ne l'utilise donc pas d'avantage à logram sur cet aspect.
Pour les algos utilisés, Logram en utilise des plus simples que apt par exemple, car celui-ci utilise un solveur SAT, mais c'est aussi la faiblesse de logram car il ne peut pas gérer tous les cas. Cela à déjà été évoquer dans un des journaux précédents, c'est un choix qu'il à fait.
Il est évident que ce genre de travail aura des répercussions sur tous les gestionnaires de paquets du monde . Et ça, c'est bien. ( surtout si c'est libre ).
C'est cette phrase qui m'a décidé à répondre. Je crois que pour l'instant en tout cas, non logram n'aura que très peu d'impact sur les autre logiciels de gestions de paquet. Ce n'est pas méchant mais réaliste. Setup à des objectifs différents c'est tout.
D'un point de vue fonctionalitées, il n'apporte rien par rapport aux autres, c'est même le contraire.
Son seul avantage c'est la rapiditée (qui demande à être confirmée sur dans les mêmes conditions que pour les autres) et les dev des autres gestionnaires de paquets sont déjà au courrant qu'ils ont des problèmes à ce niveau là, et il y a déjà des personnes qui bosse dessus.
Steckdenis, franchement, continue, ça fait plaisir de voir des gens qui se défoncent , surtout ici .
Là par contre je suis tout à fait d'accord. Il faut pas prendre mon commentaire comme une critique de Logram ou de setup, mais juste une reponse au comentaire du dessus.
Même si je ne voit pas l'utilitée de tes projets pour moi, je suis pas du genre à dire ça sert à rien il y a déjà tout ce qu'il faut. Code ce qui te fait plaisir, moi ça me fait plaisir de voir des gens coder ce qu'il aiment. Et c'est pas par ce que pour l'instant je ne voit rien qui m'intéresse personnellement que je n'y trouverais rien à l'avenir.
Et surtout, continue de nous tenir informer, j'aime bien ce genre de journaux au milieu de tout ceux qui parlent de politique ou autre.
[^] # Re: pas d'accord
Posté par Thomas Douillard . Évalué à 4.
apt, et aptitude, n'utisent pas de solveurs SAT, que je sache. Ils utilisent des algos dédiés, heuristiques, et incomplets. Ils ne garantissent pas de trouver la solution si elle existe, mais c'est pas un problème en pratique. Ils sont plus rapides qu'un solveur SAT, car plus spécialisés et avec des heuristiques dédièes, de l'optimisation pour minimiser les changement, etc.
[^] # Re: pas d'accord
Posté par beagf (site web personnel) . Évalué à 1.
Donc pour être un peu plus clair, lagestiondes dépendance est un problème NP-complet, ce qui ce prouve par une réduction du problème CNF-SAT. Et, dans aptitude, cette résolution est faite par des heuristique notament inspirées des techniques employées dans les solveurs SAT ainsi que des heuristiques supplémentaires pour choisir parmis les différentes solutions trouvées celle qui est la plus adapté au problème de gestion des dépendances.
[^] # Re: pas d'accord
Posté par Étienne . Évalué à 6.
Étienne
# Pas d'accord non plus
Posté par Barnabé . Évalué à 10.
Il faut cesser de croire que créer des paquets est compliqué. Faire un .deb est moins compliqué que ce que j'ai pu lire ici : http://logram-project.org/wiki-setup-package.html
Je le prouve :
wget ftp://ftp.vim.org/pub/vim/unix/vim-7.2.tar.bz2
tar xf vim-7.2.tar.bz2
mv vim72 vim-7.2 # nom canonique du repertoire
dh_make -b --createorig # On utilise cdbs
rm debian/*ex debian/*EX # On supprime les exemples inutiles
emacs debian/changelog # On met son nom :)
emacs debian/control # on decrit le paquet
debuild
Ceci donne un paquet équivalent à ce qui est décrit dans la page d'exemple de Setup.
Trois choses rendent la création de paquets ardue :
1 - La connaissance des outils. Le problème est le même pour tous les gestionnaires de paquets, et la documentation est le point noir pour les debs, jusqu'à ce qu'on tombe sur cette page: http://build-common.alioth.debian.org/cdbs-doc.html
2 - La bonne qualité du code. Un logiciel avec un Makefile pourri rendra difficile la création d'un paquet, pour tous les systèmes, alors qu'un soft qui sait comprendre
DESTDIR=/chemin make installla rendra facile.3 - L'adaptation au système cible, c'est à dire la séparation en plusieurs paquets binaires d'un paquet source, la création et l'application de patches, le respect de standards précis sur la place de certains fichiers... Ceci n'est absolument pas nécessaire quand on se fait un paquet pour soi, et semble encore assez éloigné des buts de Logram
Les RPMs sont un peu plus difficiles à aborder, car la syntaxe des .spec est moins standard que les Makefiles utilisés par debian, mais une fois les idiosyncrasies comprises, les tâches sont fondamentalement les mêmes.
[^] # Re: Pas d'accord non plus
Posté par Anonyme . Évalué à 5.
vim PKGBUILD && makepkgRien ne pourra battre ABS d'Archlinux ! :þ
[^] # Re: Pas d'accord non plus
Posté par beagf (site web personnel) . Évalué à 6.
D'ailleur il y a longtemps que je cherche une doc sur les bonnes conventions à adopter dans un Makefile et dans le code en général pour rendre la création des paquets simple en dehors du DESTDIR.
Globalement à chaque fois la réponses c'est utilise autoconf et automake chose que je refuse. Je ne vois pas l'interet d'utiliser un système imbitable et très lourd, qui va ajouter facilement 1Mo de fichiers à un programme qui représente 50ko de sources.
Donc en dehors du DESTDIR, qu'est ce qui est important ?
[^] # Re: Pas d'accord non plus
Posté par Barnabé . Évalué à 3.
Avoir un script configure, pas forcément issu des autotools, qui vérifie la présence des bibliothèques nécessaires et affiche clairement lesquelles manquent est un gros plus pour le packager.
Avoir un make qui ne fasse que compiler, et un make install qui ne fasse qu'installer est aussi une bonne base.
Sinon, un fichier INSTALL décrivant les éventuelles spécificités, un fichier LICENCE ou COPYING, un README contenant une description brève que le packager puisse pomper honteusement....
[^] # Re: Pas d'accord non plus
Posté par beagf (site web personnel) . Évalué à 6.
Pour le script configure, dans mon cas il faut juste un compilateur C et parfois la lib pthread, rien de sorcier, donc je me contente en général de l'indiquer clairement dans les fichiers d'info. Mais si quelqu'un à un petit script qui vérifie les deux de manière portable et qui reste très léger, pas de problèmes.
Le truc c'est plus que tout ça, ça reste très flou. Si je prend la variable DESTDIR par exemple, comment l'utiliser simplement ? Est-ce que je dois installer dans
$(DESTDIR)/bin ou dans $(DESTDIR)/usr/bin ?
Bref, moi je ne demande qu'a faciliter le travail des packageurs mais que l'on m'en donne les moyens...
[^] # Re: Pas d'accord non plus
Posté par 태 (site web personnel) . Évalué à 3.
Pourquoi voudrais-tu avoir un usr en dur au milieu d'un chemin ? Il faut installer dans $DESTDIR$PREFIX et là on trouve cette hiérarchie là : http://trac.macports.org/browser/trunk/base/doc/prefix.mtree(...) Pour les binaires, ça fait $(DESTDIR)$(PREFIX)/bin. Enfin c'est comme ça que je fais inspiré en celà par FreeBSD. http://www.freebsd.org/doc/en/books/porters-handbook/porting(...)
[^] # Re: Pas d'accord non plus
Posté par beagf (site web personnel) . Évalué à 3.
Et dans ce cas, la version simple qui consiste à faire un "make" et un "make install" ne devrait pas installer par default dans "/bin", mais au minimum dans "/usr/bin" ou "/usr/local/bin".
Ce problème ne peut pas ce règler juste avec DESTDIR, mais en effet avec PREFIX, il suffit de le mettre par defaut à "/usr" ou "/usr/local" pour que ça marche. J'avais oublié celui-là, mais la encore une petite doc sur les bon principe aurait permis de ne pas oublier...
# De la facilité avec laquelle un paquet Setup est créé
Posté par steckdenis (site web personnel) . Évalué à 2.
Deux commentaires se plaignent du manque d'arguments en faveur de la simplicité avec laquelle on peut créer un paquet Setup.
Tout d'abord, voici ce que je trouve complexe avec les paquets Deb et Rpm (pour les autres, ABS etc, j'ai dit que j'aimais bien et que je m'en étais inspiré). Pour ces deux types de paquets, créer un «paquet simple» est une affaire de minutes. J'ai eu l'occasion de tester, c'est rapide et facile.
Seulement, quand les paquets deviennent un peu complexes (plusieurs binaires, bibliothèques, etc), ça devient plus difficile. Il faut adapter le Control pour que ça marche, le fichier Rules se complexifie, etc.
Un paquet ne répondant pas strictement aux normes est également plus difficile à produire. Pour le constater, prenez le paquet sources des kdelibs, ou de tout programme KDE empaqueté par l'équipe KDE de Debian. Le rules est simple, oui, mais il commence par une ligne pour inclure une monstrueuse et complexe suite de scripts faisant en sorte que le rules marche.
Pour RPM, j'ai cru voir (mais je n'en suis pas certain) qu'il faut taper manuellement le nom de tous les fichiers qu'on veut inclure dans le paquet. Ok, c'est faisable pour Qtracker ou autre programme composé d'un petit nombre de fichiers, mais essayez un peu avec un truc un peu gros comme OpenOffice.org, FireFox, les kdelibs, etc. Vous allez en avoir vite marre.
Du côté de Setup, un paquet simple est un peu plus compliqué à faire (on a du code à taper), mais la complexité augmente bien moins quand le paquet change. Par exemple, le packagebuild contient les instructions nécessaires à la compilation, à la manière d'un pkgbuild (d'ailleurs, le nom packagebuild s'inspire bien de pkgbuild, comme quoi je sais voir ce qu'il y a de bien chez les autres :) ). Si vous suivez le LFS un de ces jours, vous verrez que toutes les lignes de commandes pour appliquer des patchs sont données. Avec Setup, il suffit de les copier/coller dans le pkgbuild. Avec un paquet Debian (je ne sais pas pour RPM), ça peut aussi se faire mais il faut une adaptation.
Pour le fichier XML, il est auto-documenté (petits commentaires, et balises XML explicites). Le principe du XML n'est pas compliqué à apprendre, même si c'est plus complexe qu'un simple fichier «Clef: Valeur» comme Debian utilise. Par contre, ça permet plein de choses, comme l'arbre DOM. C'est grâce à l'utilisation du XML que les traductions sont si faciles à faire, alors que Debian nécessite un puissant gettext (encore un exemple que Setup reste simple quand Debian se complexifie atrocement). Les règles de validation pour les questions sont également gérées par arbre DOM, ce qui permet de les regrouper, de les modifier, etc. Il y a plein d'autres exemples.
Néanmoins, j'admet que ce n'est pas si simple qu'un PKGBUILD, mais Setup s'oriente un peu plus vers l'user-friendlyness que Pacman. Avec Setup, l'utilisateur peut configurer son paquet graphiquement au moment de l'installation, toutes les chaînes de caractère traduites dans sa langue. Ça a un pris pour le développeur, oui.
[^] # Re: De la facilité avec laquelle un paquet Setup est créé
Posté par Barnabé . Évalué à 2.
Si cette argument était étayé par des exemples, il en deviendrait plus persuasif.
Mon point est que même si faire un paquet debian satisfaisant les exigences de debian est difficile, faire un paquet debian au même niveau d'exigences que celui de logram est aisé.
Par exemple, on est pas obligé de faire quoi que ce soit de spécial pour un paquet contenant plusieurs binaires. C'est un choix de la distribution, pas du système de paquet, de les traiter différemment.
[^] # Re: De la facilité avec laquelle un paquet Setup est créé
Posté par steckdenis (site web personnel) . Évalué à 1.
J'ai donné l'exemple des kdelibs après. Grosso-modo, chaque paquet un peu lourd de Debian devient fort complexe. Prends par exemple Grub, un "simple" bootloader, mais qui nécessite un fichier rules kilométrique.
Ensuite, Logram n'a pas encore d'exigence sur les paquets, du fait qu'aucun paquet officiel n'existe. Dès que Setup sera suffisamment avancé, qu'on pourra créer de beaux paquets, les exigences seront mises en places.
Et elles seront draconiennes ! Il y a «les classiques», comme les informations de debug séparées (un petit helper Sepa le permet déjà, puis une petite modification des métadonnées et c'est fait), le strip des éxécutables, etc. Il y aura aussi des choses plus complexes à mettre en oeuvre, indépendemment de Setup, comme par exemple une intégration à KDE partout où c'est possible.
M'enfin, j'avoue que tout ceci n'est pas encore très clair. Setup se développe, je réfléchis de mon côté, plus qu'à voir ce que ça va donner. Je me concentre actuellement plus sur la gestion des Deltas, avec bsdiff, pour drastiquement réduire les téléchargements (et ainsi pouvoir, avec la légèreté de Setup et de Logram DE, viser les OLPC pas puissants du tout, avec petit écran, et mauvaise connexion s'ils en ont).
[^] # Re: De la facilité avec laquelle un paquet Setup est créé
Posté par Gilles G. . Évalué à 3.
http://www.chromium.org/developers/design-documents/software(...)
[^] # Re: De la facilité avec laquelle un paquet Setup est créé
Posté par Barnabé . Évalué à 10.
Kdelibs n'est compliqué que par ce que les mainteneurs Debian le fragmentent et l'adaptent. Tu peux faire un paquet des librairies KDE avec un fichier rules de 2 lignes, dont 1 générée par dh_make :
#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/cmake.mk
Grub est l'exemple typique du paquet qui doit être maintenu par la distribution et pas par les développeurs upstream. Il est vital que son intégration avec le système soit très bien faite. De plus, le fichier rules de grub a l'air compliqué, mais il a été généré à partir du template des debhelpers, le packager ne l'a pas entièrement tapé à la main.
D'autre part, sur les exigences futures de Setup, tu verra assez vite que chacune d'elle augmente la complexité et la taille du code, et ralenti l'execution. Quand tu seras isofonctionnel avec les outils debian, tu te trouveras avec sensiblement les mêmes performances qu'eux, si tu codes aussi bien qu'eux.
Enfin, si tu veux faire des comparaisons de performance, apprend mieux à quoi servent les outils avec lesquels tu compare. Par exemple, setup search ne se compare pas à apt-cache, mais à dpkg -l, pour les exemples que tu donne.
[^] # Re: De la facilité avec laquelle un paquet Setup est créé
Posté par Guillaume Smet (site web personnel) . Évalué à 10.
Pour RPM, j'ai cru voir (mais je n'en suis pas certain) qu'il faut taper manuellement le nom de tous les fichiers qu'on veut inclure dans le paquet.
Tu as raison de ne pas en être certain. Tu peux mettre des wildcards et ce n'est pas spécialement pénible. Ca permet en outre de vérifier que ton paquet n'oublie pas de fichiers ou que tu n'as rien oublié de ce que tu avais prévu.
A l'usage, c'est un très bon garde-fou.
alors que Debian nécessite un puissant gettext
C'est pratique de toujours supposer qu'il n'y a jamais de bonne raison pour les choix de design des autres. Debian réutilise un standard archi utilisé et archi connu. Ca semble plutôt un bon choix plutôt que de réinventer la roue. Les gens le connaissent, on trouve facilement de la doc et des outils pour le gérer.
Tu supposes que c'est lourd, que ça ralentit tout mais tu as fait un peu de profiling sur le sujet ?
Même si c'était le cas, je ne suis pas sûr que la différence justifie de se passer d'un standard de fait.
Après, je suis peut-être l'exception mais je n'ai jamais spécialement été handicapé par la lenteur que tu trouves si gênante. Je n'installe pas des paquets tous les jours de manière manuelle sur mon desktop (vu que tu as l'air de vouloir traiter la problématique desktop). Et quand je le fais, je n'ai pas l'impression de perdre mon temps à attendre. Peut-être aussi parce que je ne suis pas spécialement concentré dessus et que je fais autre chose en même temps.
Par contre, la chose vraiment importante AMHA, c'est la notion de transaction. Je ne veux pas qu'un upgrade commence et me laisse mon installation à moitié en vrac si je le coupe, s'il y a un souci dans l'upgrade ou si ma machine plante pour une raison X ou Y.
Typiquement, si tu regardes ce que fait yum :
* téléchargement de tous les paquets pour être sûr de tout avoir ;
* test de la transaction ;
* si c'est validé, on va réaliser l'installation.
Il y a une très bonne raison au fait de ne pas tout lancer en parallèle. Si tu n'as pas résolu ce problème, tu peux mettre ton système de téléchargement/installation parallèle à la poubelle.
Après, tu as peut-être déjà pensé à cela mais ça ne se voit pas trop dans ce que tu présentes. Je ne vois qu'une course à la vitesse, qui n'est pas spécialement une priorité sur ce type de logiciel AMHA. C'est un plus une fois que tu as tout le reste mais pas une priorité.
Après, je n'ai pas spécialement regardé ce que tu as fait. Je voulais juste mettre en exergue quelque chose qui me gêne profondément dans la démarche : quand on essaie de faire autrement, il est important de comprendre pourquoi les précédents ont fait comme ils ont fait. Ca peut être des raisons historiques, des raisons techniques ou le fait qu'ils n'y ont pas pensé. Mais il ne faut pas forcément toujours partir du principe que les idées des autres sont moins bonnes que les siennes.
Tu fais la moitié de la démarche en allant voir ce qu'ils font mais tu pars toujours du principe qu'ils ont tort et n'ont pas de bonnes raisons de le faire. Il y a un juste milieu à trouver.
[^] # Re: De la facilité avec laquelle un paquet Setup est créé
Posté par steckdenis (site web personnel) . Évalué à 3.
Gettext n'est pas lent à l'installation, pas du tout. C'est simplement peu élégant, et encourage la non-traduction. Imagine que tu crées ton paquet perso, par exemple que le dev de Wormux crée son paquet Wormux. Il sait peut-être parler français, anglais et espagnol, mais a-t-il envie de créer des templates Gettext, de les gérer, de les traduire, et de modifier trente six mille fichiers pour que dpkg-buildpackage marche comme il faut ?
Non. Lui, il veut un truc simple. Il ne sait d'ailleurs peut-être même pas qu'on sait faire les traductions de paquets. Setup, lui, fournit une architecture de type [langue]texte[/langue] dans son fichier de métadonnées. Ainsi, si le développeur suit le tuto et se rend compte qu'on lui demande de taper :
< fr >Description< /fr >Il va se rendre compte qu'en replaçant fr par en, il peut traduire super rapidement en anglais. Oui, c'est moins "pro" que du Gettext, mais le résultat est que l'utilisateur aura un paquet dans sa langue, avec le changelog dans sa langue (super Super important ça, pour les mises à jour), une description dans sa langue, etc. C'est typiquement ce type de "finition" qu'il manque au Libre.
Prenez un Windows, et regardez. Tout, absolument tout est traduit. Les rares choses qui ne le sont pas sont des obscures programmes dans system32. Prenez votre distro préférée, même une Mandriva française. Vous trouverez sans problèmes des éléments non-traduits. Oui, le KDE est traduit. Mettez votre système à jour, recherchez un paquet, et *paf*, rien ou presque n'est traduit.
L'utilisateur anglophobe sera totalement perdu. C'est ce genre de problème auxquels il faut faire attention.
Pour le test de transaction, c'est intéressant. J'utilise Fedora et j'ai pu apprécier cet élément. Setup sera un peu plus hackish, mais fera la même chose. En effet, on peut définir l'Installation-Root d'un paquet. Il suffit, quand on installe les paquets, de les installer dans /tmp/teporarytree. Une fois que tout est installé et testé (les postinst() des paquets peuvent servir à vérifier, ainsi que les || exit 1 dans le packagebuild), on copie simplement ce dossier dans /, et c'est fait.
Ainsi, l'utilisateur répondra aux questions, ce sera rapide, et si un paquet échoue, le système est encore stable, laissé intouché. Mieux, ne pas nécessiter les droits root pour cette phase de test, mais seulement pour la copie finale.
[^] # Re: De la facilité avec laquelle un paquet Setup est créé
Posté par Barnabé . Évalué à -3.
Ce n'est pas le développeur de wormux qui fait les paquets, ce sont les packageurs des distributions.
Je ne savais pas trop où te situer, ton manque d'humilité m'aide à te placer :
Sur une échelle qui irait de Jayce à Linus, tu restes très près de Jayce, la folie en moins.
[^] # Re: De la facilité avec laquelle un paquet Setup est créé
Posté par steckdenis (site web personnel) . Évalué à -3.
Parce que sinon, ça ferait déjà longtemps qu'il y aurai un paquet Logram DE dans Debian, ou alors j'aurais la version 0.5.2 et non 0.5.1 de XMoto dans Fedora, etc.
[^] # Re: De la facilité avec laquelle un paquet Setup est créé
Posté par Guillaume Smet (site web personnel) . Évalué à 10.
Mmmh, tu as déjà parlé à des packagers ? Parce que je pense que tu te trompes en supposant que le packager va gérer lui-même les traductions dans les langues qu'il pratique (ça conduira de toute manière à des traductions approximatives, peu étant vraiment bilingues, encore moins trilingues).
La traduction est en général gérée par des équipes dédiées. Ca permet d'avoir une homogénéité dans les traductions (et même ainsi, c'est parfois peu satisfaisant).
Je vais prendre un exemple bête dans mon cas : si je fais un patch pour PostgreSQL qui demande une traduction, je ne vais pas la faire moi-même, y compris en français. Quelqu'un s'en occupe globalement et c'est bien mieux ainsi.
Accessoirement, ton fichier de méta-données avec toutes tes traductions dedans va vite devenir insupportable. Attends d'avoir du japonais et des gens qui l'éditent n'importe comment et qui vont te commiter un fichier complètement foireux.
Prenez un Windows, et regardez.
Difficile d'avoir une discussion argumentée quand tu sautes du coq à l'âne. Windows est traduit parce qu'un paquet de pognon est mis là-dedans.
Les distributions sont partiellement traduites parce que c'est un travail chiant, peu valorisant et que la majorité des gens qui le font ne sont pas payés pour le faire. Malgré toute leur bonne volonté, ils font ce qu'ils peuvent.
Accessoirement, les distributions Linux vont trop vite pour que les traductions suivent et on ne bloquera jamais une release parce que la traduction française n'est pas finie. Je suis assez sûr que chez MS, ils planifient la chose pour que le produit sorte dans une langue majeure avec *tout* traduit et plein de séances de relecture.
Une traduction homogène de qualité est un boulot titanesque (et je parle en connaissance de cause, j'avais repris les 6000-8000 clés de traduction d'un logiciel complètement histoire que tout soit homogène et cohérent - et 6000-8000, ce n'est pas bien gros quand on y pense).
L'utilisateur anglophobe sera totalement perdu. C'est ce genre de problème auxquels il faut faire attention.
Et tu penses que personne n'y a pensé avant toi ? Le manque de traduction n'a pas grand chose à voir avec une difficulté technique. C'est juste un manque de ressources dédiées à cela dans la durée.
Et espérer le résoudre en répartissant la traduction sur les packagers, ça donnera un truc aussi bien que les systèmes de traduction distribués où chacun traduit une chaîne en passant : rien de bien cohérent.
Setup sera un peu plus hackish, mais fera la même chose. En effet, on peut définir l'Installation-Root d'un paquet. Il suffit, quand on installe les paquets, de les installer dans /tmp/teporarytree. Une fois que tout est installé et testé (les postinst() des paquets peuvent servir à vérifier, ainsi que les || exit 1 dans le packagebuild), on copie simplement ce dossier dans /, et c'est fait.
Tu as bien en tête que la copie de fichiers n'est pas atomique ? Et qu'il ne va pas suffire de copier ? Il va aussi falloir supprimer les fichiers qui ne sont plus nécessaires, remonter d'éventuels conflits sur des fichiers de configuration existants suite à modification du fichier du paquet... Que se passe t-il avec ton système si le disque / est full pendant la copie ?
Je m'intéresse assez peu au sujet donc je n'ai aucune idée de comment rpm et dpkg ont réglé ces problèmes (et s'ils l'ont fait complètement d'ailleurs) mais tu n'as pas l'air d'en avoir plus et c'est inquiétant.
Si ça pète dans certains cas et que je me retrouve avec une installation cassée que je dois refaire, je vais vraiment être super content d'avoir gagné 2 secondes chaque mois quand je rajoute un paquet.
A mon avis, il faut vraiment que tu te poses et que tu réfléchisses à ce que veulent vraiment les gens. Tu verras que leur priorité n°1 sur un gestionnaire de packages est d'avoir un truc à toute épreuve.
Les gens ont grogné sur yum quand la lenteur était vraiment insupportable. Depuis que c'est acceptable sans être mirifique, les gens ne se plaignent plus trop.
Que tu attaques en réfléchissant à la performance et que tu en fasses une préoccupation majeure, pourquoi pas, il va bien falloir que tu te différencies. Mais sans avoir la vision globale de comment tu vas régler le problème du "rock solid", tu risques quand même fort d'arriver dans le mur à la fin.
Après, tu fais bien ce que tu veux. C'était juste un éclairage différent en passant sur ta démarche.
[^] # Re: De la facilité avec laquelle un paquet Setup est créé
Posté par wismerhill . Évalué à 5.
Je m'intéresse assez peu au sujet donc je n'ai aucune idée de comment rpm et dpkg ont réglé ces problèmes (et s'ils l'ont fait complètement d'ailleurs) mais tu n'as pas l'air d'en avoir plus et c'est inquiétant.
Ce n'est en tout cas pas géré au niveau de RPM, j'ai déjà eu le cas d'une partition /boot trop pleine et un système laissé dans un état difficile à récupérer parce que la génération du initrd n'avait pas pu se terminer.
C'est d'ailleurs une raison pour laquelle il est difficile d'anticiper les problèmes de place disponibles lors de l'installation de paquets car un script de post-installation peut de générer une quantité significative de fichiers (par exemple une distribution LaTeX qui pré-calculerait ses polices metafont dès l'installation, ça peut vite se chiffrer en dizaines de Mo).
[^] # Re: De la facilité avec laquelle un paquet Setup est créé
Posté par tanguy_k (site web personnel) . Évalué à 3.
Dans le cas de Setup, QtScript (donc du Javascript) est tout indiqué a mon avis : faire des boucles, utiliser des conditions, des fonctions et des regexp ca peut etre tres utile.
Reste a definir alors une jolie API qui s'appuie sur QtScript.
D'ailleurs sous Windows les principaux outils pour creer des installers s'appuient sur des languages et y ajoutent une API. Inno Setup : Pascal, NSIS : C
[^] # Re: De la facilité avec laquelle un paquet Setup est créé
Posté par Troy McClure (site web personnel) . Évalué à 3.
[^] # Re: De la facilité avec laquelle un paquet Setup est créé
Posté par Hobgoblins Master (Mastodon) . Évalué à 2.
# Dépendances
Posté par barmic . Évalué à 4.
Juste sur le choix des bibliothèques utilisées. Tu utilise la STL+Qt. Je ne vois pas d'inconvénient à tout ça mais peut être que boost, qui est très performante, pourras t'aider par ses qualités esthétiques et du point de vu de la performance.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.