Le Guide du Nouveau “Committer” | ||
---|---|---|
Précédent |
Lisez s'il vous plaît d'abord la section sur la copie des archives.
Pour importer un nouveau logiciel, le plus facile est d'utiliser la procédure easy-import sur freefall. Elle vous
posera quelques questions et importera directement le logiciel dans le répertoire que
vous aurez indiqué. Elle a été écrite par Jörg Wunsch <joerg@FreeBSD.org>
, envoyez-lui s'il vous
plaît un courrier électronique si vous avez des questions à propos de easy-import.
Il y a une chose qu'elle ne fera pas à votre place : ajouter le logiciel au Makefile du répertoire de niveau supérieur (catégorie). Il faudra le faire vous-même.
Vérifiez votre portage, pour vous assurez qu'il compile et que le paquetage est correctement construit. Voici ce qu'il est recommandé de faire :
% make install % make package % make deinstall % pkg_add le_paquetage_que_vous_venez_de_compiler % make deinstall % make reinstall % make package
Le chapitre faire vous-même un portage du Manuel de Référence vous donnera des instructions plus détaillées.
Utilisez portlint(1) pour vérifier la syntaxe du portage. Il n'est pas indispensable d'éliminer la totalité des messages d'avertissement, mais veillez à régler les problèmes les plus évidents.
Si le logiciel porté a été soumis par quelqu'un qui n'a jamais collaboré au projet auparavant, ajoutez le nom de cette personne à la section Autres Collaborateurs du Manuel de Référence.
Fermez le PR, si le portage résulte d'un PR. Pour fermer un PR, il suffit d'exécuter
edit-pr PR# sur
freefall et de modifier la valeur de la variable state
de open
en closed
. On vous demandera d'entrer un commentaire, et c'est
tout.
Quand vous voulez importer un logiciel en rapport avec un autre logiciel déjà archivé dans un autre répertoire, envoyez s'il vous plaît un courrier électronique au responsable des logiciels portés pour lui demander son avis. En rapport désigne ici une version différente ou une version légèrement modifiée. En exemple, on peut citer print/ghostscript* (versions différentes) et x11-wm/windowmaker* (version Anglaise et version internationalisée).
Comme autre exemple, on peut citer le cas d'un logiciel porté déplacé d'un sous-répertoire à un autre, ou d'une modification du nom d'un répertoire parce que l'auteur a changé le nom de son logiciel, bien qu'il dérive d'un logiciel déjà importé.
Quand il n'y a pas d'historique à conserver. Si un logiciel est importé dans une catégorie erronée et immédiatement déplacé, il suffit d'un simple cvs remove de l'ancien suivi d'un cvs import du nouveau.
Envoyez un courrier électronique au responsable des logiciels portés, qui fera la copie de l'ancien emplacement vers le nouveau. Vous en serez averti, et l'on attendra alors de vous que vous exécutiez les opérations suivantes :
cvs remove de l'ancien logiciel (si besoin est),
Correction du Makefile de niveau supérieur (catégorie),
Mise à jour de CVSROOT/modules
Si d'autres logiciels dépendent de celui qui vient d'être mis à jour, correction des lignes décrivant leurs dépendances dans leurs Makefiles,
Si le logiciel a changé de catégories, modification en conséquence de la ligne CATEGORIES du Makefile du logiciel.
Avant livraison d'une nouvelle version, il est nécessaire de limiter les interventions sur les archives des logiciels portés pendant une courte période, le temps que les paquetages et la version elle-même soient compilés. Cela pour garantir la cohérence entre les différents composants de la version, c'est cela que l'on appelle le “gel des logiciels portés”.
Pendant le gel des logiciels portés, vous ne devez pas soumettre quoi que ce soit dans l'arborescence des logiciels portés, sauf autorisation explicite du responsable des logiciels. “Autorisation explicite” correspond ici à l'un des deux cas de figure suivants :
Vous avez posé la question au responsable des logiciels, et il vous a répondu : “Allez-y, intégrez”.
Le responsable des ports vous a envoyé un courrier électronique, soit directement, soit à la liste de diffusion, pour signaler un problème à corriger sur le logiciel.
Notez bien que vous n'êtes pas implicitement autorisé à corriger un logiciel pendant un gel simplement parce qu'il ne compile plus.
Le responsable des logiciels portés enverra des messages d'avertissement sur la liste de diffusion à propos du catalogue des logiciels portés de FreeBSD et la liste de diffusion pour les committers de FreeBSD pour annoncer la mise en oeuvre prochaine d'une nouvelle version, habituellement deux à trois semaines à l'avance. La date exacte ne sera définitivement fixée que quelques jours avant. Cela parce que le gel des logiciels doit être synchronisé avec la mise en oeuvre de la version elle-même, et que ce n'est qu'à ce moment-là que l'on sait exactement quand cette opération aura lieu.
Quand le gel commencera, il y aura bien sûr une nouvelle annonce sur la liste de diffusion pour les committers de FreeBSD.
Quelques heures après la mise en place de la nouvelle version, le responsable des logiciels enverra un courrier électronique à la liste de diffusion à propos du catalogue des logiciels portés de FreeBSD et à la liste de diffusion pour les committers de FreeBSD pour annoncer la fin du gel des logiciels. Remarquez que la finalisation de la version n'implique pas automatiquement la fin du gel. Nous devons nous assurer qu'un problème de dernière minute ne demande pas de reconstruction immédiate de la version.
Commencez par consulter http://bento.FreeBSD.org/~asami/errorlogs/. Vous y trouverez les messages d'erreurs des dernières compilations des logiciels portés sous 3-stable et 4-current.
Néanmoins, il ne suffit pas qu'un logiciel n'y apparaisse pas pour pouvoir dire qu'il compile correctement. (Une de ses dépendances, par exemple, peut ne pas avoir compilé.) Voici les répertoires de bento, n'hésitez pas à aller y voir :
/a/asami/portbuild/3/errors messages d'erreur de la dernière compilation de 3-stable /logs tous les messages de la dernière compilation de 3-stable /packages messages d'erreur sur les paquetages de la dernière compilation 3-stable /bak/errors messages d'erreur de la dernière compilation intégrale de 3-stable /bak/logs tous les messages de la dernière compilation de l'intégrale de 3-stable /bak/packages messages d'erreur sur les paquetages de la dernière compilation intégrale de 3-stable /4/errors messages d'erreur de la dernière compilation de 4-current /logs tous les messages de la dernière compilation de 4-current /packages messages d'erreur sur les paquetages de la dernière compilation 4-current /bak/errors messages d'erreur de la dernière compilation intégrale de 4-current /bak/logs tous les messages de la dernière compilation de l'intégrale de 4-current /bak/packages messages d'erreur sur les paquetages de la dernière compilation intégrale de 4-current
Essentiellement, si le logiciel apparaît dans packages, ou dans logs mais pas dans errors, il compile correctement. (Les répertoires errors contiennent ce que vous voyez sur la page Web.)
Non. Le responsable des logiciels portés regénère l'INDEX et l'intègre régulièrement aux archives.
Tous les fichiers immédiatement dans ports/, et tous les fichiers des sous-répertoires dont le nom commence par une majuscule (Mk, Tools, etc.). Le responsable des logiciels est particulièrement susceptible pour ce qui touche à ports/Mk/bsd.port.mk, n'y touchez donc pas à moins que vous ne vouliez affronter son courroux.
Ce document, ainsi que d'autres peut être téléchargé sur ftp.FreeBSD.org/pub/FreeBSD/doc/.
Pour toutes questions à propos de FreeBSD, lisez la documentation avant de contacter <questions@FreeBSD.org>.
Pour les questions sur cette documentation, contactez <doc@FreeBSD.org>.