Orientations techniques

Noyau, terre sacrée

Contrairement au cas d'autres logiciels, nous ne devrions jamais nous amuser à patcher le noyau. Le noyau Linux de Nasgaïa doit rester le dernier noyau officiel de la branche stable, sauf bug sévère avéré, auquel cas le dernier fonctionnel est retenu.

Cela exclut tous les services, logiciels, fonctionnalités qui nécessitent une modification du code source du noyau. Par contre, cela n'exclut en rien des logiciels qui installent des modules additionnels pour le noyau (comme alsa) - du moins après que des tests aient montré l'absence de problèmes.

Le but est de rester le plus proche possible de la réalité, que l'utilisateur puisse par la suite upgrader son kernel sans être privé de services qui n'existent pas dans la version officielle - et c'est aussi une manière de faire confiance aux développeurs du noyau: s'ils pensent que ça n'a pas (ou pas encore) sa place dans le kernel, il y a généralement de très bonnes raisons, et vu que le kernel est la pièce maîtresse, faisons leur confiance.

Enfin, si l'utilisateur souhaite patcher son noyau (il y a certains cas où cela peut-être intéressant pour une utilisation très spécifique), il saura qu'il part d'un noyau officiel, et pourra agir en conséquence sans se compliquer trop la vie.

Services

Essayons de garder le nombre de services lancés au démarrage le plus bas possible, de prendre le parti de méta-démons comme xinetd quand cela est possible, présumer le moins possible de ce que les gens sont censés vouloir/faire/avoir.

Cela n'exclut en rien le fait de proposer divers services qui peuvent être très utiles, mais par exemple, le système par défaut ne devrait pas obliger d'installer des choses comme cron, anacron, atd, un MTA, serveur DNS etc... Considérons cela comme un héritage important de la philosophie LFS qui prouve que tout cela n'est en rien indispensable.

Les divers services init (simpleinit) doivent contenir une ligne descriptive de la forme:

Cela pourra permettre aux outils d'administration d'exposer le rôle d'un service, et aider à la prise de décision (ex: activer ou désactiver ce service)

Rapprochement vers la FHS

Le système très cloisonné des versions jusqu'à nga-0.9 incluse pour installer les paquets (essentiellement dans /opt) ayant rempli son rôle de test pendant la mise en place du projet, nous revenons à une approche compatible FHS (ou qui tendra à l'être).

Xfree revient dans /usr/X11R6 (même si je maintiens que techniquement il n'a rien à faire là ;o), des liens /usr/{bin,lib,include}/X11 ont été ajoutés pour suivre la FHS et simplifier la compilation de certaines applications.

Je propose de garder l'idée de ne pas installer dans /usr/X11R6 des choses extérieures (certaines distros y installent netscape ou mozilla), à l'exception de polices (TTF additionnelles ou les polices de GhostScript, qui y ont leur place).

Nous continuons à ne rien installer dans /usr/local, qui est réservé à l'usage exclusif de l'utilisateur (qui a de ce fait un endroit où installer ce qu'il a compilé sans craindre de toucher au système fourni par les nba).

/opt/{sbin,bin,lib,include,share} n'est plus utilisé par les nba, tout comme /usr/local; seuls les /opt/PACKAGE seront utilisés quand requis; l'essentiel de ce que nous y installions a migré vers /usr.

Spécificités compatibles avec la FHS

Pour les pages de man et infos, nous n'utilisons que PREFIX/share/{man,info}, où PREFIX peut être /usr, /opt/PAQUET - jamais PREFIX/{man,info) - nos outils de post-installation de ces pages ne prennent ces pages en compte que dans ce cas.

Depuis le passage à simpleinit, utilisation de /etc/init.d au lieu de /etc/rc.d/init (cela contrevient sans doute à la LSB, mais peu importe) - l'organisation interne de /etc/init n'est pas encore définitivement choisie.

Gestionnaire de fenêtres

À compléter.

Nsetup

À compléter.

Patches

Bien souvent, l'utilisation de patches est très pratique soit pour modifier des erreurs dans du code source, ou pour mettre en valeur des changements à un document (comme la source en sgml de celui-ci). Le format à privilégier est ce que l'on appelle le diff contextuel unifié (diff -urN pour differ deux hiérarchies, diff -u pour deux simples fichiers). Dans le cas de modifications très vastes, essayez de générer un jeu de patches plutôt qu'un énorme patch fourre tout (cela fait moins de travail à "casser" le patche pour en extraire les parties intéressantes).

Précision pour Ncooker2

Il est recommandé de bzipper tous les patches dans les répertoires patches/ des Nbuilds, afin de restreindre leur taille au maximum, et d'utiliser le suffix .diff (.diff.bz2 donc)

Compression

Les formats officiels utilisés pas Nasgaïa sont tar pour l'archivage, et bzip2 pour la compression, pour le gain de place, et donc de temps pour les téléchargements. Les binaires nba sont aussi des archives tar, qui contiennent les données au format de compression maximale (data.tar.bz2).

Optimisations, options etc...

La plupart des paquets, sauf exceptions sont compilés avec comme optimisations pour CFLAGS et CXXFLAGS: -s -O3 -march=i686 -mcpu=i686. Les scripts de compilation exécutent toujours des fonctions de strip standardisé (voir la doc sur les formats de nba/Nbuilds), sauf dans les cas connus où cela pose problème.

Cela s'est avéré être une bonne méthode, réduisant au maximum la taille des binaires et libs, tout en conservant un système capable de compiler absolument proprement (la preuve, Nasgaïa est compilée elle-même dans ces conditions)

Un système prêt pour le développement

C'est là aussi une extension de la philosophie LFS, nous installons pour chaque paquet l'intégralité de ce que le développeur à prévu d'installer; en mots simples, cela veut dire que nous ne nous amusons pas à placer les fichiers d'entêtes (*.h) et archives d'objets (*.a contenant les *.o nécessaires par exemple pour la compilation statique) dans des paquets séparés.

Toutefois, pour ceux qui n'en auront pas l'usage (un peu dommage d'utiliser Nasgaïa dans ce cas là.....), le manuel proposera des commandes toutes simples pour effacer tout cela et gagner de la place. Le but est que l'installation d'un .nba offre les mêmes avantages que si on le compilait soi-même - les erreurs, temps de compilation, tests à rallonge en moins.

Exceptions

Quelques rares paquets pourront peut-être être sujets à une dissociation runtime/dev (je pense à mozilla and co et gpm) pour des raisons pratiques ou de logique.