Ça dépend des dépôts. ReiserFS est conçu pour ce genre de choses, donc je veux bien croire que ça aille vite. Il faut aussi compter l'age de l'installation d'ArchLinux. Mon premier update s'est fait en quelques secondes, alors que je suis maintenant à près d'une minute (avec le système inutilisable à cause des IO).
2)
Justement, tu prends en fait la 2e solution. Pour obtenir les dépendances d'un paquet, tu dois faire une requête. Pour chaque dépendance, tu dois prendre leurs dépendances, et ainsi de suite. Finalement, tu te retrouves avec une quantité impressionnante de requêtes sur ta BDD.
Tu peux également faire un gros SELECT qui te ramène toutes les deps, ce qui est justement ma solution 1.
3)
Non, je ne mélange pas. Je parle en fait d'accès, et je n'oppose pas le mmap contre l'accès séquentiel, mais bien l'idée «Je passe par une lib tier à laquelle je parle en requête textuelle» par rapport à «Je fait tout moi-même, sans couche d'abstraction». Sauf que les fichiers mmapés ont également comme avantage d'être plus rapides et d'utiliser moins de RAM (le noyau les considère comme un swap supplémentaire, et utilise un chemin de code rapide et optimisé pour lire les pages, au lieu de passer par des syscalls lents et répétitifs).
4)
La base de donnée est écrite par Setup lui-même (il récupère du serveur des fichiers de texte comme ceux utilisés par Debian, donc en gros du INI). Il n'y a donc aucun problème d'edianess ou d'alignement, le compilateur se charge de tout.
Le fait que ce soit illisible par d'autres programmes n'est pas embêtant pour deux points. Premièrement, Setup utilise une bibliothèque, donc un programme qui veut gérer des paquets utilise cette bibliothèque. Deuxièmement, ce n'est pas comme si c'était un fichier de configuration ou un dépôt de mails, devant être lu par tout le monde. C'est le cache de Setup, ça doit juste être rapide et sûr.
Si un programme devait néanmoins lire la liste des paquets installés, il lui suffit de lire /var/cache/lgrpkg/db/installed_packages.list. C'est un fichier INI lisible avec un QSettings. Setup lit ce fichier quand il reconstruit sa base de donnée (oui, ma BDD a comme problème d'être en lecture seule, donc quand on met à jour, il faut l'effacer et la reconstruire. Ça prend 6 secondes pour y mettre les 27 000 paquets de Sid).
[^] # Re: Gestionnaire de paquets de Chakra
Posté par steckdenis . En réponse au journal Chakra se sépare d'Arch. Évalué à 3.
1)
Ça dépend des dépôts. ReiserFS est conçu pour ce genre de choses, donc je veux bien croire que ça aille vite. Il faut aussi compter l'age de l'installation d'ArchLinux. Mon premier update s'est fait en quelques secondes, alors que je suis maintenant à près d'une minute (avec le système inutilisable à cause des IO).
2)
Justement, tu prends en fait la 2e solution. Pour obtenir les dépendances d'un paquet, tu dois faire une requête. Pour chaque dépendance, tu dois prendre leurs dépendances, et ainsi de suite. Finalement, tu te retrouves avec une quantité impressionnante de requêtes sur ta BDD.
Tu peux également faire un gros SELECT qui te ramène toutes les deps, ce qui est justement ma solution 1.
3)
Non, je ne mélange pas. Je parle en fait d'accès, et je n'oppose pas le mmap contre l'accès séquentiel, mais bien l'idée «Je passe par une lib tier à laquelle je parle en requête textuelle» par rapport à «Je fait tout moi-même, sans couche d'abstraction». Sauf que les fichiers mmapés ont également comme avantage d'être plus rapides et d'utiliser moins de RAM (le noyau les considère comme un swap supplémentaire, et utilise un chemin de code rapide et optimisé pour lire les pages, au lieu de passer par des syscalls lents et répétitifs).
4)
La base de donnée est écrite par Setup lui-même (il récupère du serveur des fichiers de texte comme ceux utilisés par Debian, donc en gros du INI). Il n'y a donc aucun problème d'edianess ou d'alignement, le compilateur se charge de tout.
Le fait que ce soit illisible par d'autres programmes n'est pas embêtant pour deux points. Premièrement, Setup utilise une bibliothèque, donc un programme qui veut gérer des paquets utilise cette bibliothèque. Deuxièmement, ce n'est pas comme si c'était un fichier de configuration ou un dépôt de mails, devant être lu par tout le monde. C'est le cache de Setup, ça doit juste être rapide et sûr.
Si un programme devait néanmoins lire la liste des paquets installés, il lui suffit de lire /var/cache/lgrpkg/db/installed_packages.list. C'est un fichier INI lisible avec un QSettings. Setup lit ce fichier quand il reconstruit sa base de donnée (oui, ma BDD a comme problème d'être en lecture seule, donc quand on met à jour, il faut l'effacer et la reconstruire. Ça prend 6 secondes pour y mettre les 27 000 paquets de Sid).