Points à vérifier pour chaque portage logiciel sous OpenBSD

1. Si vous voulez prendre en charge la gestion d'un portage logiciel, inscrivez- vous via : ports@openbsd.org.
   • Cette liste est consacrée à toutes les discussions et votre inscription y est fortement recommandée.
   • La lecture des envois précédents sur cette liste est essentiel : des annonces ou explications cruciales s'y trouvent.
   • Vous pourrez y cotoyer des personnes expérimentées dans ce domaine. Ils pourront vous offrir des conseils ou tester vos portages.
   
   
2. Prendre en charge la gestion d'un portage signifie beaucoup plus que de proposer des logiciels. Pour chaque logiciel, vous vous engagez à maintenir vos portages à jour et répondre aux questions des utilisateurs qui les utiliseront : comment activer ou désactiver certaines fonctionnalités, etc.
   
   
3. Votre décision prise, vous devez obtenir une copie locale sur votre disque de l'arbre des ports à l'aide de cvs. Comment faire ? Vous trouverez toutes les informations nécessaires dans la page consacrée à AnonCVS.
   
   
4. Choisissez dans quel dossier sera placé votre portage et créez l'infrastructure de base requise. Utilisez le fichier Makefile modèle /usr/ports/infrastructure/templates/Makefile.template. NEED_VERSION est considéré comme obsolète et vous ne devez plus l'utiliser pour les nouveaux portages : mettez à jour votre arbre local des ports, ceci incluant bsd.port.mk.
   • Créez le répertoire pkg.
   • Créez des fichiers vides pkg/DESCR, pkg/PLIST.
   
   
5. Ajoutez les portions "fetch" (de récupération) au Makefile.
   • Modifiez EXTRACT_SUFX si le suffixe des fichiers n'est pas .tar.gz. D'autres exemples sont .tar.Z ou .tgz.
   • Modifiez DISTNAME : cette variable locale doit contenir le nom du fichier, sans son suffixe. Par exemple si votre portage logiciel est foo-1.0.tar.gz alors DISTNAME doit contenir la chaîne : foo-1.0.
   • Modifiez MASTER_SITES pour contenir l'URL des répertoires qui contiennent un exemplaire du fichier portant les sources. Par exemple il peut s'agir de l'adresse ftp://ftp.openbsd.org/pub/OpenBSD/distfiles/. N'oubliez pas la barre finale de l'adresse ! Essayez d'avoir au moins trois sites différents pour chacun de vos portages. Le site le plus fiable et rapide doit se trouver en première position.
   • Gardez à l'esprit que les variables locales suivantes sont utilisées pour identifier le fichier à récupérer et dans cet ordre : ${MASTER_SITES}${DISTNAME}${EXTRACT_SUFX}. Toutes ces variables seront utilisées. Par conséquence, il ne faut pas que DISTNAME contienne le nom complet du fichier.
   • Vous pourrez vérifier que vous avez fixé correctement ces variables en utilisant la commande : make fetch-all.

   Certains portages logiciels sont complexes et des outils supplémentaires sont à votre disposition pour simplifier votre tâche :

   • Vous pouvez utiliser la variable locale PATCHFILES. Cette dernière doit contenir une liste de patches proposés par l'auteur du logiciel (et non OpenBSD). On y trouve généralement des correctifs de fiabilité ou de sécurité.
   • Si vos ports sont disponibles au sein de sites miroirs majeurs tels que GNU, SunSite ou CPAN, nous proposons une liste de sites au sein du fichier /usr/ports/infrastructure/templates/network.conf.template. Modifiez MASTER_SITES par : ${MASTER_SITE_GNU} ou ${MASTER_SITE_SUNSITE}, etc. Pour simplifier ce processus, utilisez la construction ${MASTER_SITE_FOO:=subdir/} pour rajouter le sous- répertoire contenant la distribution.
   • Chaque portage contient une version spécifique d'un logiciel. Une fois les fichiers récupérés, on vérifie un hachage pour s'assurer de leur intégrité et la comparaison sera effectuée à partir des hachages que vous aurez calculés. Pour éviter toute confusion, DISTFILES et PATCHFILES doivent avoir des numéros de version clairement identifiables : ne récupérez pas de fichier foo-latest.tar.gz s'il existe un lien vers foo-1.0.5.tar.gz. Si c'est nécessaire, contacter l'auteur du logiciel afin de lui demander conseil et expliquez poliment pourquoi vous devez pouvoir identifier clairement un numéro de version dans le fichier contenant les sources de votre portage en devenir.
   • Si votre portage logiciel requiert plus de 5 DISTFILES + PATCHFILES pour fonctionner, utilisez la variable locale DIST_SUBDIR pour éviter de polluer et de rendre complexe la lecture de /usr/ports/distfiles par les utilisateurs (et déterminer qui fait partie de quoi).
   • DIST_SUBDIR ne doit pas référencer de numéros de version. Lorsque le portage sera mis à jour vers une nouvelle version, seuls les fichiers contenant les sources doivent être modifiés : si DIST_SUBDIR est modifié, tous les fichiers seront à nouveau récupérés. Il faut penser à l'utilisateur qui doit maintenir son système ou tout du moins pouvoir en consulter l'état sans s'égarer.
   • A la fois DISTFILES et PATCHFILES ne proviennent pas nécessairement des mêmes sites MASTER_SITES. Il est possible de définir des sites supplémentaires à l'aide des variables locales MASTER_SITES0 à MASTER_SITES9. Il vous suffit d'écrire DISTFILES=foo-1.0.5.tar.gz:5 pour récupérer le fichier depuis le site contenu dans MASTER_SITES5 (notez le ":5").
   • Certains portages n'ont pas besoin de récupérer tous les fichiers en toute circonstance. Par exemple, les options de compilation de certains portages logiciels définissent ce qui doit être compilé ou non, des sortes de "modules" optionnels. Si une fonctionalité présente dans un module n'est pas utilisée, alors il n'est pas nécessaire de récupérer tous les fichiers mais uniquement ceux qui sont requis. Certains composants sont également spécifiques à certaines architectures matérielles : tous ces fichiers optionnels doivent être référencés dans la variable locale SUPDISTFILES. Lorsque des cibles de compilation telles que makesum ou mirror-distfiles sont utilisées, le système des Ports veillera à récupérer tous les fichiers optionnels même si ceux-ci ne sont pas toujours requis par l'utilisateur classique.
   
   
6. Créez des hachages dans distinfo en tapant make makesum. Vous devez ensuite vérifier que ces hachages sont valides en tapant make checksum.
   • Dans de rares cas, il n'est pas possible de disposer de hachages pour tester l'intégrité des sources. Il est de votre responsabilité d'essayer de trouver par tous les moyens possibles un site d'archive fiable. Communiquer avec l'auteur ou les auteurs du logiciel et la ou les personnes en charge des sites contenant les archives du logiciel est fondamental et recommandé. Dans le pire des cas, vous pourrez utiliser la variable locale IGNOREFILES pour marquer les fichiers pour lesquels il n'est pas possible de disposer de hachages d'intégrité fiables.
   • Tous les fichiers de DISTFILES seront traités durant la phase d'extraction. EXTRACT_ONLY peut-être utilisé pour limiter l'extraction aux seuls fichiers requis (peut être vide). L'usage habituel de cette variable est de personnaliser l'extraction : par exemple, si certains DISTFILES doivent subir un traitement particulier, il seront retirés de EXTRACT_ONLY et gérés manuellement après la phase d'extraction. Pour des raisons historiques, make extract fixe le répertoire de travail pendant l'extraction des fichiers. Ainsi, il est très inhabituel de fournir des chemins de pré-extraction et post-extraction différents (et c'est même un comportement suspect, indiquant un camouflage important au sein du portage).
   • Les correctifs qui demandent un traitement particulier doivent être mentionnés dans DISTFILES et retirés de EXTRACT_ONLY, pour des raisons historiques.
   
   
7. Testez l'extraction du portage à l'aide de la commande make extract. Vous devez vérifier avec soin où se trouve la base des sources. Il s'agit normalement de w- ${PKGNAME}${FLAVOR_EXT}/${DISTNAME}. Vous aurez peut-être besoin de modifier la variable WRKDIST du Makefile si cette base de sources est différente.
   
   
8. Lisez la documentation d'installation et notez que la construction du port doit être complétée et doit prendre en compte toute option spéciale requise.
   
   
9. Maintenant vous devez prendre le temps de considérer sérieusement et avec un grand soin les licences (ou la licence) qui couvre votre portage logiciel. Certains logiciels peuvent être redistribués librement, mais pas tous. Afin de vous aider, vous devez répondre à quatre questions. Il s'agit des variables PERMIT_* que vous trouverez au sein du fichier Makefile.
   • PERMIT_PACKAGE_CDROM indique si le portage peut être distribué sur support CD-Rom.
   • PERMIT_PACKAGE_FTP indique si le portage peut être placé sur des sites FTP.
   • PERMIT_DISTFILES_CDROM indique si nous avons le droit de placer en miroir les distfiles sur support CD-Rom.
   • PERMIT_DISTFILES_FTP indique si nous avons le droit de placer les distfiles en miroir sur des sites FTP.

   A chaque fois que l'un de ces usages est autorisé, indiquez "Yes". Si ce n'est pas le cas, vous devez expliquer pourquoi dans une chaîne commentaire. Soyez attentif (attentive) aux conditions spéciales qui sont imposées après l'installation du logiciel. Par exemple, une série de logiciels impose qu'un exemplaire de leur licence soit installée et mentionnée à l'utilisateur. Dans ce cas, nous vous recommandons de mettre la licence dans /usr/local/share/doc/<name>/.

   En plus des valeurs PERMIT_*, mettez un indicateur de license tel que # License au dessus de ces valeurs en commentaire. Ainsi, nous saurons pourquoi les valeurs PERMIT_* sont positionnées de cette manière.
   
   

10. Ajoutez les options de configuration au Makefile et créez un script de configuration au besoin.
    • Vous pouvez ajouter un script de configuration de votre portage nommé `configure' et le situer dans un répertoire scripts/. Ce script sera exécuté avant toute configuration spécifiée par la variable locale CONFIGURE_STYLE.
    • Si le configure GNU est utilisé, vous devriez utiliser ./configure --help afin de déterminer quelles options sont disponibles.
    • Tout ce que vous pourriez être amené à modifier peut être modifié en utilisant le drapeau de configuration -option dans le paramètre CONFIGURE_ARGS du fichier Makefile.
    • Utilisez CONFIGURE_ARGS+= pour rajouter une ou plusieurs options à cette variable locale. Si vous utilisez CONFIGURE_ARGS= vous risquez d'écraser tout contenu préalable.
    
    
11. Essayez de construire le portage logiciel à l'aide de la commande make build.
    • Si vous avez de la chance, tout sera construit sans la moindre erreur (bonne chance !)
    • Si vous obtenez une erreur, vous devrez générer un ou plusieur patch qui seront utiliés par votre portage, afin de permettre sa compilation et installation sous OpenBSD. Déterminez ce qui doit être modifé, et créez un patch.
    • Les correctifs doivent toujours s'appliquer depuis la base ${WRKDIST}.
    • Le moyen le plus facile de vérifier que le correctif fonctionne est de tout "nettoyer" à l'aide de make clean patch. Cette commande va nettoyer le répertoire de travail de tout fichier, faire à nouveau l'extraction et appliquer votre correctif.
    
    
12. Commencez un cycle de make build, puis produisez un patch (ou utilisez make update-patches) puis make clean patch.
    • Les correctifs doivent être placés dans patches/ et doivent être nommés patch-* où vous remplacerez * par quelque chose de compréhensible. Nous vous recommandons de nommer vos patch patch- FILENAME où FILENAME est le nom du fichier qui sera modifié par le correctif. (make update-patches le fait automatiquement pour vous)
    • Appliquer PATCHFILES est la première étape du stade des patch. Vous pouvez l'invoquer séparément à l'aide de make distpatch, une cible utile pour les porteurs d'applications. Vous pouvez ignorer cette étape si vous n'avez pas fixé de valeur à cette variable.
    • Chaque fichier de patch ne doit modifier qu'un seul fichier à la fois. S'il-vous-plaît.
    • Utilisez make update-patches pour générer les correctifs.
    • Tous les correctifs DOIVENT être relatifs à ${WRKDIST}.
    • Vérifiez que les correctifs NE CONTIENNENT PAS de tags qui risquent d'être modifiés par cvs. Si c'est le cas, vos correctifs ne pourront plus s'appliquer après une mise à jour via cvs. Vous pouvez vérifier les changements potentiels à l'aide de -kk pour l'éviter.
    • Ecrivez une petite note explicative au début du fichier contenant le correctif décrivant le role de ce dernier (non obligatoire).
    • Veuillez fournir un exemplaire de vos correctifs à l'auteur du logiciel.
    
    
13. Essayez de paramétrer SEPARATE_BUILD.
    • Si le portage peut construire des fichiers objets en-dehors de l'arbre des sources, cela est préférable et permet de conserver l'arbre des sources dans un état plus "propre" (de nombreux programmes qui utilisent CONFIGURE_STYLE=gnu le peuvent) et cela simplifie en outre la gestion de l'arbre de sources sur plusieurs architectures.
    • Ceci peut vous épargner des efforts et vous permettre de relancer facilement un cycle de construction du portage depuis le configure.
    
    
14. Parcourez avec attention la sortie obtenue (s'il y en a) et modifiez toute option utile dans le Makefile. Pour répéter la commande utilisez `make clean configure'.

    Note: vérifiez que les fichiers dépendants de l'hôte soient placés soit dans /etc ou /etc/<name>, mais NE REMPLACEZ NI NE MODIFIEZ JAMAIS de fichiers existants dans /etc. Il vaut mieux placer ces fichiers dans /usr/local/share/<name> puis copiez vers /etc ou /etc/<name> seulement si les fichiers n'existent pas. Si les fichiers existent, affichez un message et indiquez à l'utilisateur du système quels fichiers doivent être modifiés. Cela permet également de garantir que les fichiers seront inclus dans le paquetage puisque tout ce qui se trouve dans /usr/local sera inclus dans PLIST. Une fois un paquetage installé, le contenu de pkg/MESSAGE sera affiché et le cycle de construction du paquetage sera terminé.

    OpenBSD situe les fichiers comme suit :

       exécutables utilisateur :                                 /usr/local/bin
       exécutables de l'administrateur :                         /usr/local/sbin
       programmes exécutables :                                  /usr/local/libexec
       bibliothèques :                                              /usr/local/lib
       données indépendantes de l'architecture :                 /usr/local/lib/<nom>
       fichiers inclus installés :                               /usr/local/include ou /usr/local/include/<nom>
    
       données spécifiques à la machine :                        /etc ou /etc/<nom>
       état local :                                              /var/run
       fichiers contenant les scores des jeux :                  /var/games
       fichiers info GNU :                                       /usr/local/info
       pages man :                                               /usr/local/man/...
       données indépendantes de l'architecture en lecture seule :/usr/local/share/<nom>
       documentations diverses :                                 /usr/local/share/doc/<nom>
    

15. Commencez un cycle de compilations jusqu'à ce que le portage soit terminé. Patchez (voir ci-dessus), puis clean et make jusqu'à la production du portage. Vous devez éliminer tous les "warning" obtenus en particulier ceux en rapports avec la sécurité du code produit.
    
    
16. Contrôlez la sémantique de SEPARATE_BUILD. Vous ne devez le faire que si votre portage utilise la variable locale SEPARATE_BUILD. Idéalement, le portage ne doit pas modifier de fichiers dans ${WRKSRC} après l'application de votre patch. Vous pouvez le vérifier en retirant vos droits d'écriture à cette étape sur ${WRKSRC}. Ensuite vous pouvez utiliser SEPARATE_BUILD=concurrent -- et vérifier qu'une autre personne peut, sur une autre architecture, obtenir la même compilation. Sinon, utilisez SEPARATE_BUILD=simple -- si la construction du portage sur plusieurs architectures peut provoquer des problèmes, à mesure que certains fichiers seront régénérés à certains moments.
    
    
17. Ajoutez une ligne COMMENT dans le Makefile. COMMENT est une COURTE description du portage (au maximum 60 caractères). Vous ne DEVEZ PAS INCLURE le nom du paquetage dans la description ou son numéro de version. Vous ne devez PAS faire débuter cette ligne de commentaire par un caractère en majuscule sauf si la signification sémantique doit être sans aucune ambiguïté et NE TERMINEZ PAS CETTE LIGNE par un point. EN AUCUN CAS VOUS NE DEVEZ COMMENCER PAR UN ARTICLE INDEFINI COMME 'un' OU 'une' ; retirez tout article au début.
    
    
18. Editez pkg/DESCR et pkg/PLIST.
    • DESCR est une description plus étendue du portage. Il peut s'agir d'un ou plusieurs paragraphes expliquant de manière consise en quoi consiste le logiciel. Nous vous invitons à terminer chaque ligne après 72 caractères ce que vous pouvez faire après l'écriture de ce fichier en utilisant la commande suivante : fmt -w 72
    • PLIST doit rester vide pour l'instant.
    
    
19. Si l'application a besoin de créer un utilisateur ou un groupe, choisissez le plus petit identifiant libre dans /usr/ports/infrastructure/db/user.list afin de l'utiliser pour votre port et soyez certain que celui-ci soit ajouté à ce même fichier lors de son entrée dans l'arbre.
    
    
20. Installez l'application avec make fake. Les librairies ne devraient jamais faire l'objet d'un "strip". Les exécutables subissent un "strip" par défaut; ce comportement est dicté par ${INSTALL_STRIP}. ${INSTALL_PROGRAM} respecte cette variable automatiquement. Ceci est préférable à une application inconditionnelle de "strip" (à l'aide d'une cible "install-strip" ou en exécutant "strip" à partir du Makefile par exemple). Vous pouvez utiliser file afin de déterminer si un binaire à fait l'objet d'un "strip" ou pas.
    
    
21. Vérifier une nouvelle fois et avec le plus grand soin que votre portage ne contient pas de trous de sécurité potentiels. Les programmes qui fonctionnent en setuid où qui accèdent au réseau doivent faire l'objet d'un audit complet et de grand soin. Nous vous invitons à étudier nos recommandations quant à la sécurité pour mener à bien cette étape très importante. Vous devez tout enregistrer et étudier en ce qui concerne tout changement, et l'inscrire au sein du fichier /SECURITY. Ce fichier doit lister avec précision tout problème de sécurité potentiel introduit par votre portage, avec les correctifs qui accompagnent les programmes afin que quiconque qui prenne votre portage en main puisse savoir ce qu'il reste à vérifier. Par exemple :

          $OpenBSD$
    
          ${WRKDIR}/receiver.c
             l'appel de la fonction mktemp (fonction wrapper à
             do_mktemp) me semble incorrecte.
    
          Ce serveur utilise une grande quantité de fonctions
          strlcpy/strlcat/snprintf.
    

    
    
    
22. Soyez certain que votre répertoire /etc/mtree est bien à jour (la prochaine étape utilise mtree afin de supprimer les répertoires existants des fichiers PLIST générés). Souvenez-vous qu'une mise à jour ne touche pas /etc...
    
    
23. Créez le fichier pkg/PLIST. Une fois l'installation complète, utilisez la commande pour développeurs make plist qui permet de générer le fichier PLIST au sein du répertoire pkg. Ce fichier est le candidat pour toute création de liste de paquetages.

    Lisez attentivement le fichier `PLIST' et vérifiez que tout a bien été installé à l'endroit approprié. Tout ce qui n'a pas été installé peut être ajouté avec une règle `post-install' dans le Makefile du port.

    Les portages qui installent des bibliothèques partagées auront un fichier supplémentaire, nommé PFRAG.shared.

    • PLIST décrit les fichiers indiquant pour chaque architecture si les bibliothèques partagées sont ou non supportées.
    • PFRAG.shared ne décrit que les fichiers qui sont installés de manière additionnelle sur les architectures qui supportent les bibliothèques partagées.
    • PFRAG.noshared ne décrit que les fichiers qui sont installés en supplément sur les architectures qui ne supportent pas les bibliothèques partagées.
    
    
    
24. Vérification de la dépendance envers des bibliothèques partagées. Lancez make port-lib-depends-check et ajoutez chaque annotation à LIB_DEPENDS ou WANTLIB jusqu'à ce que cette commande se termine sans erreur. Vous devriez lire le guide de mise à jour afin de comprendre pourquoi cela est important.
    
    
25. Si vous avez ajouté une entrée dans LIB_DEPENDS, relancez make plist. En effet, il est possible que certains répertoires n'ont plus besoin d'être référencés dans la PLIST s'ils sont installés par une dépendance.
    
    
26. Testez le paquetage lui-même. Après l'installation du portage, la commande make package est utilisée pour créer un paquetage. Pour tester le paquetage, utilisez d'abord la commande pkg_add puis utilisez pkg_delete.
    
    
27. Vérifiez les dépendances. Utilisez vos logs pour vérifier que le port a bien détecté les dépandances mentionnées dans DEPENDS, ni plus ni moins. Vérifiez qu'il n'y a pas de de dépendances cachées. Par exemple, il pourrait y avoir des éléments détectés suite à l'installation de quelques ports auparavant).
    
    
28. Vérifiez les dépendances relatives à des libraries partagées. Utilisez pour cela la commande make lib-depends-check et ajoutez toutes les annotations LIB_DEPENDS et WANTLIB afin qu'aucune erreur ne soit retournée (utilisez make clean=package afin de supprimer l'ancien paquetage après avoir mis à jour le Makefile relatif au port). Pour comprendre pourquoi c'est si important, veuillez consulter les conseils de mise à jour
    
    
29. Exécutez les tests de régression et vérifiez qu'ils se déroulent correctement. Positionnez NO_REGRESS=Yes pour un port si ce dernier ne possède pas d'infrastructure de test. Notez qu'il ne faut pas positionner NO_REGRESS pour un port qui a une infrastructure de régression vide.
    
    
30. Envoyez un email à l'adresse ports@openbsd.org avec une courte note indiquant vos commentaires et les tests menés. Attachez le port/patch à cet email et envoyez-le (les archives des listes ne contiennent que le courrier seul).

    Essayez de faire tester votre portage sur le plus grand nombre de plates-formes possibles.

    • Les systèmes AMD64 Opteron sont excellents car ils sont rapides et parce que sizeof(int) != sizeof(long) sur cette plate-forme.
    • Les Sun SPARC et UltraSPARC sont aussi d'excellentes plates-formes de test car elles sont faciles à trouver, et parce que l'ordre des octets est inverse à celui de la plate-forme i386; si vous développez sur SPARC, vous devriez évidemment tester le code sur i386.
    
    
31. Intégrez toutes les informations obtenues que vous obtiendrez d'autres testeurs. Testez à nouveau sur votre plate-forme. Ensuite, répondez à toute personne et proposez leurs votre nouveau portage.
    
    
32. Enfin, incorporez votre logiciel dans l'abre des "ports" d'OpenBSD. Si vous ne disposez pas de droits d'écriture CVS, demandez à quelqu'un qui en dispose sur ports@openbsd.org de le faire pour vous.
    
    
33. Si vous êtes un développeur disposant d'un accès CVS, insérez votre portage logiciel. Nous préférons l'utilisation de "import" pour importer votre nouveau port, plutôt que d'ajouter des centaines (ou plus) de fichiers de manière individuelle. Import utilise des numéros de version de type "branche vendeur" comme 1.1.1.1 mais ne vous inquiétez pas à ce sujet ! :-) Si vous modifiez un fichier de manière spécifique (édition puis cvs commit), la nouvelle version sera alors 1.2.

    En résumé, l'importation sera utilisée à la création du portage logiciel. A partir de ce stade, "cvs add" et "cvs rm" seront utilisés pour ajouter ou retirer des fichiers, tandis que le cycle classique d'édition puis de commit sera utilisé. Vous pouvez utiliser quelque chose comme :

    $ cd kaffe1
    $ make clean    # évitez d'envoyer vos fichiers de travail dans le CVS !
    $ cvs -d cvs.openbsd.org:/cvs import -m 'kaffe port' ports/lang/kaffe1 \
            VotreNom VotreNom_YYYY-MMM-DD
    

    • -d cvs.openbsd.org:/cvs indique où se trouve le cvs. Vous pouvez l'ignorer si vous avez une variable locale CVSROOT définie.
    • -m 'kaffe port' est votre message de login. Vous pouvez indiquer ce que vous voulez
    • ports/lang/kaffe1 est le chemin relatif où votre portage sera placé par rapport au /cvs
    • VotreNom (remplacé par votre nom de login) est le 'tag vendeur'. Vous êtes le vendeur puisque vous l'importez.
    • VotreNom_YYYY-MMM-DD (e.g., ian_2000-Jan-01) est le 'tag de distribution vendeur'. Valeur informative.
    
    Comme exemple réel, voici la sortie obtenue par la mise en place d'un portage que nous avons réalisé le 8 septembre 1998 :

    $ cd kaffe1
    $ make clean >/dev/null
    $ cvs import -m 'kaffe1.0(==JDK1.1) port' ports/lang/kaffe1 ian ian_1998-Sep-
    08 ian@cvs.openbsd.org's password: (caché, évidemment)
    I ports/lang/kaffe1/CVS
    I ports/lang/kaffe1/files/CVS
    I ports/lang/kaffe1/pkg/CVS
    N ports/lang/kaffe1/Makefile
    cvs server: Importing /cvs/ports/lang/kaffe1/files
    N ports/lang/kaffe1/files/md5
    cvs server: Importing /cvs/ports/lang/kaffe1/pkg
    N ports/lang/kaffe1/pkg/COMMENT
    N ports/lang/kaffe1/pkg/DESCR
    N ports/lang/kaffe1/pkg/PLIST
    
    No conflicts created by this import
    $ 
    

34. Enfin, ajoutez une ligne d'entrée pour le nouveau portage dans le Makefile du répertoire parent; par exemple si nous ajoutons le portage de ports/lang/kaffe1, nous l'ajoutons également au fichier ports/lang/Makefile.
    
    
35. Vous devez maintenir le portage ! Si jamais un problème survient ou si une nouvelle version paraît etc. vous devez tout faire pour maintenir votre portage à jour. En d'autres termes, cycle de construction du portage, mise à jour, nouveau cycle de construction, etc.
    
    
36. Lors de la mise à jour d'un portage, n'oubliez pas de traiter les dépendances ! Vous ne devez pas provoquer un dysfonctionnement en modifiant votre portage, car d'autres logiciels peuvent en dépendre ! En cas de problème, si votre portage demande la mise à jour d'autres portages sous la charge d'autres personnes, contactez ces derniers. De même, surveillez tout portage pouvant affecter les votres et préparez vous à des mises à jour sans être toujours prévenu(e) à l'avance.