# Pas besoin de build-dependecies, tous les fichiers .h ont été parsés, et le code se trouve directement dans le fichier bytecode.
Donc tu risques d'avoir des redondances fâcheuses (et lourdes). Si je télécharge des programmes KDE - par exemple - via un gestionnaire de paquets lambda, il ne téléchargera que le paquet (éventuellement les trucs nécessaires au runtime, mais seulement la première fois). Si je fais de même avec Gentoo - par exemple - il récupérera les dépendances nécessaires à la compilation, mais une sule fois.
Par contre, avec ton truc, _chaque_ programme récupéré par le gestionnaire de paquets va se trimballer une grosse partie des kdelibs (dans mon exemple) avec lui. Ce qui est bien, mais pas top.
Ce qui n'enlève rien à l'intérêt de ton concept. Une solution qui permettrait - au moins partiellement - de limiter le problème que je soulève serait de faire un diff binaire (xdelta?) entre les différents paquets "logiquement" liés en amont, pour ensuite morceler les téléchargements. Genre "tu as besoin de digikam et d'amarok, alors je te fournis d'abord la partie commune - kdelibs, qt &co - puis les parties spécifiques et tu te chargeras de tout regrouper". On peut même envisager un cache côté client pour ces mêmes parties communes. Si ta technique est vraiment aussi économe en place que tu le dis, le cache ne sera pas _très_ couteux.
# Dépendances?
Posté par Larry Cow . En réponse au journal LLVM dans un gestionnaire de paquets ?. Évalué à 4.
Donc tu risques d'avoir des redondances fâcheuses (et lourdes). Si je télécharge des programmes KDE - par exemple - via un gestionnaire de paquets lambda, il ne téléchargera que le paquet (éventuellement les trucs nécessaires au runtime, mais seulement la première fois). Si je fais de même avec Gentoo - par exemple - il récupérera les dépendances nécessaires à la compilation, mais une sule fois.
Par contre, avec ton truc, _chaque_ programme récupéré par le gestionnaire de paquets va se trimballer une grosse partie des kdelibs (dans mon exemple) avec lui. Ce qui est bien, mais pas top.
Ce qui n'enlève rien à l'intérêt de ton concept. Une solution qui permettrait - au moins partiellement - de limiter le problème que je soulève serait de faire un diff binaire (xdelta?) entre les différents paquets "logiquement" liés en amont, pour ensuite morceler les téléchargements. Genre "tu as besoin de digikam et d'amarok, alors je te fournis d'abord la partie commune - kdelibs, qt &co - puis les parties spécifiques et tu te chargeras de tout regrouper". On peut même envisager un cache côté client pour ces mêmes parties communes. Si ta technique est vraiment aussi économe en place que tu le dis, le cache ne sera pas _très_ couteux.