Bonsoir,
Bonjour,
Voici un petit mail pour vous faire part de mes intérrogations vis à vis de
la
gestion des dépendances dans Ncooker.
Il n'est pas trop tard pour y apporter des modifications et je suis ouvert à
toutes améliorations.
J'aimerais préciser, s'il en est besoin, que le but de ce mail n'est pas de
relancer une série de débats comme on en a connu par le passé. Il fait
suite à
une discussion avec Julien au cours de laquelle notre point de vue a
_positivement_ divergé ce qui nous a poussés a souhaiter plus
d'informations.
Je confirme. :)
Ncooker scinde les dépendances en trois :
builddeps
Ces dépendances doivent être satisfaites pour qu'un programme puisse
être
compilé.
basicdeps:
Ces dépendances doivent être satisfaites pour qu'un programme puisse
être
éxécuté.
fulldeps:
Ces dépendances sont obtenues de manière automatique à partir des
programmes/fichiers résultants de la phase `build'. Elles reflètent
des
dépendances à satisfaire pour que les éxcutables puissent-être ..
éxécutés.
Je suis globalement d'accord avec toi jusque là mais j'ai deux remarques :
1) Je préfère les termes "construit" et "utilisé" en lieu et place des
termes "compilé" et "executé". C'est plus générique.
2) le fichier "fulldeps" n'est pas obligatoirement obtenu de manière
automatique. Rien ne t'empêche de te passer de Ncooker et de créer un paquet
NBA avec en y mettant les fichiers qui vont bien. Ncooker n'est finalement
qu'un outil permettant de faciliter la création de paquets NBA.
Comme je le souligne dans le rapport de bug #6967 [1], je pense que
`bascideps'
ne devrait pas être analysé lors de la commande `build' [2].
Julien pense au contraire que les dépendances doivent être vérifiées lors
de la
commande 'build', auquel cas la séparation des dépendances n'a plus de sens
et
ajoute même une certaine compléxité tant pour les traitements que pour la
création (par les humains) des Nbuilds.
En fait, je suis parti de l'idée que la plupart des dépendances
d'utilisation sont des dépendances de construction. Par exemple, un
programme en GTK+ aura besoin de GTK+ pour la construction et pour
l'utilisation. A partir de là, il me semblait dommage de forcer le
développeur de Nbuild à répéter les mêmes dépendances dans les deux
fichiers.
Il me semble donc évident qu'il faut soit modifier le comportement de
Ncooker
de façon à ce qu'il n'évalue que `builddeps' lors de la commande `build'
(ce
que je suis prêt à faire), soit simplifier la stratégie vis à vis des
dépendances.
Sur ce dernier point, on peut même envisager n'utiliser qu'un seul fichier.
L'idée du fichier builddeps est plutôt de lister les dépendances d'outils
nécessaires à la construction du paquet (compilateur, make, langage de
scripts, ...). Il me semble donc nécessaire d'avoir deux fichiers.
Le fait est que nous ne sommes pas tombés d'accord sur ce point mais que
nous
avons tous deux considéré l'avis de l'autre avec intérêt car ils ont tous
deux
des avantages et des inconvénients.
Je suis d'accord que l'un et l'autre points de vue se valent. J'espère que
d'autres personnes apporteront leur grain de sel. ;)
Mon autre question concerne le contenu des fichiers de dépendances [3]. Il
est
possible d'y spécifier, outre le nom d'un paquet, le nom d'un fichier tel
que
`lib/foo' ou encore `bin/bar'.
Cela a probablement été discutté par le passé, mais je pense qu'il s'agit
d'une
mauvaise idée.
En effet, si on dispose d'un paquet `foo' qui dépend du fichier `bin/baz',
Ncooker doit disposer de la liste _complète_ des fichiers fournis par
_tous_
les paquets éxistants pour résoudre corrèctement les dépendances.
Cela soulève de nombreux problèmes:
- Liste de fichiers lourde ;
- Résolution des dépendances lourde ;
- Compléxité induite pour créer un dépot [4].
Ce comportement est d'autant plus discuttable que la base de données de
paquets
installés sur le système créant le paquet dispose de _tous_ les éléments
nécessaires pour résoudre 'nom de fichier' -> 'paquet'.
Au final, et selon moi, l'utilisateur ne devrait pas pouvoir spécifier de
noms
de fichiers (ce n'est pas plus simple pour lui et n'apporte au final pas
grand
chose). Ncooker devrait en revanche continuer à utiliser ses procédés
automatiques de génération des dépendances et résoudre la relation 'nom de
fichier' -> 'paquet' lorsque nécessaire.
A vrai dire, je ne comprends pas vraiment le problème. Est-ce que tu
pourrais préciser s'il te plait ?
Néanmoins, je te donne quelques précisions sur le fonctionnement de Ncooker
:
- lorsque qu'une dépendance précise un nom de fichier et un paquet, on
regarde d'abord si le paquet existe puis ensuite, on vérifie que le fichier
fait bien partie du paquet ;
- le fichier fulldeps est généré de sorte qu'il y ait toujours un paquet
précisé pour chaque dépendance (exceptions faites des fichiers fulldeps
faits à la main, ou des fichiers fulldeps générés avec l'option
--ignore-deps) ;
- lorsqu'une dépendance ne précise qu'un fichier et que ce fichier est
manquant, il n'est pas prévu qu'on indique le paquet à installer pour
résoudre la dépendance.
Voilà pour mes remarques. Bisous et à un de ces jours.
[1] https://gna.org/bugs/?6967
[2] `fulldeps' n'est pas concerné car il n'existe pas encore.
[3] C'est cela dont j'ai oublié de te parler Julien.
[4] Le seul moyen d'obtenir la liste des fichiers fournis pas un paquet est
de
le construire (build).
--
Benoit Myard <[EMAIL PROTECTED]> [0x3EEC1AEC] :wq!
A+
--
JulienL
_________________________________________________________________
Windows Live Messenger sur i-mode : dialoguez avec vos amis depuis votre
mobile comme sur PC ! http://mobile.live.fr/messenger/bouygues/
_______________________________________________
Nasgaia-dev mailing list
[email protected]
https://mail.gna.org/listinfo/nasgaia-dev
