Ce serait loin d'être marrant, tu perdrais surtout beaucoup d'avantages comme le gain d'espace (mémoire et disque dur) ou la correction des failles de sécurité pour tous les programmes qui utilisent la bibliothèque.
Si j'ai bien compris, la gestion des dépendances automatiques se résume à une analyse statique du binaire (sûrement à coup de ldd) pour connaître les bibliothèques utilisées puis à une recherche dans une base de donnée pour trouver les paquets associés.
On pourrait faire plus intelligent pour construire les dépendances au moment du build. Avec un crochet(hook) dans ld qui interroge directement la base de donnée, télécharge le paquet et continue son build.
Il faudrait aussi un crochet dans pkg-config ainsi qu'une analyse du code source pour trouver les dlopen. Et j'oublie sûrement plein d'autres cas de figure.
Donc beaucoup de travail pour un intérêt limité et qui de plus se limite aux langages type C/C++.
[^] # Re: .
Posté par Corentin Rossignon . En réponse au journal NuTyX, une distribution atypique. Évalué à 1. Dernière modification le 23 mars 2015 à 11:07.
Ce serait loin d'être marrant, tu perdrais surtout beaucoup d'avantages comme le gain d'espace (mémoire et disque dur) ou la correction des failles de sécurité pour tous les programmes qui utilisent la bibliothèque.
Si j'ai bien compris, la gestion des dépendances automatiques se résume à une analyse statique du binaire (sûrement à coup de ldd) pour connaître les bibliothèques utilisées puis à une recherche dans une base de donnée pour trouver les paquets associés.
On pourrait faire plus intelligent pour construire les dépendances au moment du build. Avec un crochet(hook) dans ld qui interroge directement la base de donnée, télécharge le paquet et continue son build.
Il faudrait aussi un crochet dans pkg-config ainsi qu'une analyse du code source pour trouver les dlopen. Et j'oublie sûrement plein d'autres cas de figure.
Donc beaucoup de travail pour un intérêt limité et qui de plus se limite aux langages type C/C++.