Re: [Actux] une pensée de Marcus J. Ranum |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/actux Archives
]
- To: actux@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [Actux] une pensée de Marcus J. Ranum
- From: dermiste <dermiste@xxxxxxxxx>
- Date: Mon, 23 Jun 2008 09:42:55 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=EiZJA1kUYk8BWUxXJrCMqcJ+uGOgQjKwQBnKHcw4sIg=; b=K9WxBntYivkBcKVzXCrE/3Wm7+5kZSuWmAuGmy9yxfFgexcBfCv1pVBXwQTUixg6a5 sfl3KnCrYJyy4yCtpqJcSHb853f6zxZvbs9RhcEiCzg+ah6O3KoTtBH0lQPpGdWFOhuj rwNEIwK/lqvEh0Oz6JLnfMPQ3vCMq7aOQDg5Q=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=d7IBxxMcY00FbMv43nsVmz1k9bWRW8Yu8PHog2+WdzLma5cT72+ggJukJITDxNUvyG h4lwQTgMgfZOgzxVihWmHEDUeAjTM689i95wlEEAUQPNfnxV9DD95FyAKF7LFUU6dI1t U6YeSpsMHdMajPGJvac72ZnuaGbuD7ygnRaYk=
2008/6/23 JackDesBwa <jackdesbwa@xxxxxxxxx>:
>> lisaison dynamique ne veut pas
>>
>> nécéssairement dire dépendances optionnelles... on peut lier
>> dynamiquement des librairies nécéssaires à l'execution du binaire....
rien n'empeche de créer un stub pour les dépendances optionnelles. On
peut imaginer que lors d'un appel, le stub envoie un message demandant
l'installation de la dependance, si l'utilisateur accepte, alors
l'appel est suspendu le temps que l'installation se fasse, puis que
le linker refasse la bonne liaison (merci PLT et GOT), sinon ca
renvoie une valeur bidon ou ca s'arrete. Ca demande une réécriture du
linker (surtout si on rajoute les demandes d'installation par
invocation), et les techniques utilisées sont proche de celle des
codes viraux (confusion pour AV ou IDS), mais c'est faisable, si le
code est bien structuré.
> L'idée est que ce ne sont pas les "pré-paquets" qui gèrent les dépendances
> mais le "convertisseur de pré-paquet en paquet".
> Typiquement, le pré-paquet peut être du XML :
>
> <pre-paquet>
> <meta>
> <equipe>
> <developpeur>Truc</developpeur>
> <developpeur>Machin</developpeur>
> <graphiste>Truc</graphiste>
> </equipe>
> <site>http://</site>
> [...]
> </meta>
> <options>
> <compil_option exclus="gtk">qt</compil_option>
> <compil_option exclus="qt">gtk</compil_option>
> <exec_option>bonjour</exec_option>
> </options>
> <compil>
> [Script bash ou lien vers le script, on peut imaginer que le meta-paquet
> est dans l'archive des sources]
> <option id="bonjour">[idem avec la partie "bonjour" en sus]</option>
> [Bout de script commun]
> <option id="qt">[idem]</option>
> <option id="gtk">[idem]</option>
> [Autre bout de script...]
> </compil>
> </pre-paquet>
>
> Le dit "convertisseur" compile avec les options que le mainteneur de la
> distribution a choisi.
> Une fois compilé, il examine les liaisons des binaires créés et puisque la
> distribution a bien fait son outil de conversion, il repère dans quels
> paquets se trouvent ces bibliothèques et établit les dépendances, et les
> dépendances "optionnelles" cités par l'auteur dans le fichier. (si ce que tu
> appelles dépendances optionnelles sont celles qui ne sont proposées par le
> programme que si celles-ci sont disponibles)
>
> C'est une idée à développer, je donne simplement l'embrillon que la
> discussion m'a inspiré.
> Après il serait intéressant de standardiser les noms d'options, de pousser
> davantage la réflexion sur le fonctionnement, etc...
>
> JackDesBwa
>
Sinon ya une approche qui consiste a dire que la facilité
d'intégration contribue a la qualité d'un logiciel. Ce standard de
méta-paquet, c'est une solution technique à un probleme
organisationel, et il faudra bien se dire a un moment qu'aucune API ne
remplace une bonne documentation et une bonne conception. Ce qui
serait vraiment utile dans le cas présent, c'est un recueil de bonnes
pratiques, écrit par les packagers de ttes les distros de ts les OS.