Glop, je n'ai pas internet pour le moment, mais vive le télétravail,
je profite de ce midi pour répondre :-)

Le 20/06/06, Julien L.<[EMAIL PROTECTED]> a écrit :
>Arf, non, s'il vous plait, pas de relance de débats. Je déteste déja
>la décision de faire des packages en XML, ce qui à mon sens n'apporte
>aucun avantage et complique la tâche. On a eu assez de débats ces deux
>dernières années, je préfère accepter les décisions qui ont été prises
>(bonnes généralement), et faire avec.

La décision d'utiliser le fichier XML pour le fichier "infos" n'avait été
que très peu débattu. Gontran était parti sur cette approche car il fallait
bien essayer quelque chose. Si le format XML ne s'avère pas pratique, je
pense que ce choix peut mériter d'être remis en cause.

Le mieux est de faire comme Julien: on fait son bout de code pour voir
ce que ça donne, puis on propose le truc. S'il y a un réel avantage et
plait à la majorité des gens, on peut l'utiliser, puisqu'il l'a déjà
codé, sinon, ba on reste sur l'existent.

>Et Ngadkm ?
>
>Je trouve que c'est un super projet. Il se trouve que je n'en ai pas
>eu besoin, mais ça sera un vrai avantage dans le futur. En attendant,
>alfs vous construit une lfs version développement sans aucun problème
>(une fois que vous avez compris comment ça marche ;).

Je ne connais pas ALFS mais je me décide à poser la question stupide
suivante : à quoi sert NgaDkm si ALFS permet déjà de faire le travail ?

1) certains paquets de LFS/*LFS ne sont pas utilisés par Nga, d'autres
peuvent les remplacer. Certaines compilations diffèrent.

2) il automatise certaines tâches comme la préparation de la cible
(création du système de fichiers, montage automatique, vidage de
l'environnement de l'utilisateur qui lance le processus, etc..). Bien
que cela ne soit pas indispensable, c'est bien pratique pour ceux qui
ne veulent pas s'embêter avec tous ces détail. De plus, en cas
d'erreur, il trace tout et 'se rappelle' de là où il s'est arrêté,
permettant de le relancer sans tout recompiler.

3) Le but ultime de Ngadkm est de fournir une base de Nga en
s'appuyant sur Ncooker. En lançant Ngadkm, on prépare d'abord une
plateforme de compilation (équivalent du chapitre 5, mais avec
quelques suppléments), puis il prépare le devkit (ensemble minimal de
nba constituant la base de la distro) en lançant Ncooker de mainère
automatisée. De ce fait, on dispose d'un devkit et des nbas permettant
de l'avoir.

Donc Ngadkm n'est pas indispensable, mais permet de simplifier la
tâche du développeur de Nasgaïa. Le portage sur différentes plateforme
(comme amd64 dont je dispose) pourra également être grandement
simplifié.

Pour l'instant, Ngadkm est au calme plat (désolé). Afin de gagner en
rapidité de livraison, je compte pour l'instant oublier la préparation
automatique de la cible, et me concentrer sur la génération de la
plateforme de compilation:
1) générer une chaine de compilation autonome
2) récupérer le dernier Ncooker valide
3) générer un tarball de cette plateforme de compilation
3) lancer Ncooker séquentiellement pour générer le devkit et les nbas.
4) générer un tarball de ces nbas, contenant un outil permettant de
les installer à la guise de l'utilisateur.

@+
--
Richard 'riri' GILL
jabber: [EMAIL PROTECTED]
http://riri.houbathecat.info
http://www.gnurou.org/Writing/SmartQuestionsFr

_______________________________________________
Nasgaia-dev mailing list
[email protected]
https://mail.gna.org/listinfo/nasgaia-dev

Répondre à