> - Si un groupe de développeurs ne suit pas les libs concernées, à un moment
> donné il va y avoir un problème de version dans le paquet. Inclure les libs
> permet de se passer de ce genre de problème, qui peut être bloquant, sans que
> rien d'autre que le numéro de version n'ait changé pour le groupe en question
>
> - Pour la sécurité, j'ose imaginer que l'équipe qui fait le projet sait d'où
> vient ce qu'elle y a inclus , et est capable de s'abonner aux avis et en tenir
> compte.
En fait, tu dis que c'est chiant pour les développeurs de suivre les nouvelles
versions des libs qu'ils utilisent, mais que c'est moins chiant qu'ils
s'abonnent aux avis de sécurité sur les libs qu'ils utilisent ?
Ça n'a absolument aucun sens.
> - La mémoire, c'est uniquement la place du binaire sur le disque dur. Rien ne
> change à l'usage, quand tu fais un #include 'toto.h" ou un #include
> "/usr/lib/toto.h" si les deux libs sont identiques. Et même s'il faut y
> réfléchir, c'est quoi , 300ko de + , lorsque le To est à 70€ ? le soupçon de
> sérénité ?
Heu je pense que t'as pas compris. Un header contient juste en théorie les
prototypes des fonctions et les déclarations de types, en gros c'est utile qu'au
moment de la compilation et on s'en cogne.
En revanche, le linkage statique va inclure toute la lib dans l'executable, et
donc va l'alourdir, là où le linkage dynamique permet de charger la lib au
moment de l'exécution, et donc elle n'est présente sur le système qu'une seule
fois.
> - La collaboration, c'est si possible, et si on modifie la lib de façon
> conforme aux objectifs. Quand je vois que le paquet Epiphany inclue Gecko ,
> c'est à dire Firefox en entier sous FreeBSD, je me dis que quelque fois, les
> libs, ça pourrait être mieux géré. Si je devais faire un navigateur utilisant
> Gecko, crois moi, je prendrait tout ce qui concerne Gecko dans Firefox, mais
> ça serait du rm de tout le reste, et pas de remontées, peut -etre une énieme
> libGecko qui sera plus à jour à la prochaine update de firefox. ( à côté,
> webkit est dispo beaucoup plus facilement :s )
Bah dans ce cas là, la solution c'est qu'une libgecko développée upstream et
utilisée par Firefox soit bien faite, pas de pomper le code et de l'inclure dans
ton soft. Qu'est-ce que tu fais pour merger les modifs upstream de gecko après ?
> Quant à sqlite, en même temps, ce truc est fait pour être inclus dans les
> programmes . Sinon, faut travailler avec du lourd.
Heu j'ai peur de pas comprendre ce que tu veux dire.
[^] # Re: Debian a raison
Posté par tesiruna . En réponse à la dépêche Pas de Chromium pour Debian Squeeze. Évalué à 2.
> donné il va y avoir un problème de version dans le paquet. Inclure les libs
> permet de se passer de ce genre de problème, qui peut être bloquant, sans que
> rien d'autre que le numéro de version n'ait changé pour le groupe en question
>
> - Pour la sécurité, j'ose imaginer que l'équipe qui fait le projet sait d'où
> vient ce qu'elle y a inclus , et est capable de s'abonner aux avis et en tenir
> compte.
En fait, tu dis que c'est chiant pour les développeurs de suivre les nouvelles
versions des libs qu'ils utilisent, mais que c'est moins chiant qu'ils
s'abonnent aux avis de sécurité sur les libs qu'ils utilisent ?
Ça n'a absolument aucun sens.
> - La mémoire, c'est uniquement la place du binaire sur le disque dur. Rien ne
> change à l'usage, quand tu fais un #include 'toto.h" ou un #include
> "/usr/lib/toto.h" si les deux libs sont identiques. Et même s'il faut y
> réfléchir, c'est quoi , 300ko de + , lorsque le To est à 70€ ? le soupçon de
> sérénité ?
Heu je pense que t'as pas compris. Un header contient juste en théorie les
prototypes des fonctions et les déclarations de types, en gros c'est utile qu'au
moment de la compilation et on s'en cogne.
En revanche, le linkage statique va inclure toute la lib dans l'executable, et
donc va l'alourdir, là où le linkage dynamique permet de charger la lib au
moment de l'exécution, et donc elle n'est présente sur le système qu'une seule
fois.
> - La collaboration, c'est si possible, et si on modifie la lib de façon
> conforme aux objectifs. Quand je vois que le paquet Epiphany inclue Gecko ,
> c'est à dire Firefox en entier sous FreeBSD, je me dis que quelque fois, les
> libs, ça pourrait être mieux géré. Si je devais faire un navigateur utilisant
> Gecko, crois moi, je prendrait tout ce qui concerne Gecko dans Firefox, mais
> ça serait du rm de tout le reste, et pas de remontées, peut -etre une énieme
> libGecko qui sera plus à jour à la prochaine update de firefox. ( à côté,
> webkit est dispo beaucoup plus facilement :s )
Bah dans ce cas là, la solution c'est qu'une libgecko développée upstream et
utilisée par Firefox soit bien faite, pas de pomper le code et de l'inclure dans
ton soft. Qu'est-ce que tu fais pour merger les modifs upstream de gecko après ?
> Quant à sqlite, en même temps, ce truc est fait pour être inclus dans les
> programmes . Sinon, faut travailler avec du lourd.
Heu j'ai peur de pas comprendre ce que tu veux dire.