[BACK]Return to checklist.html CVS log [TXT][DIR] Up to [local] / www

Diff for /www/Attic/checklist.html between version 1.19 and 1.20

version 1.19, 2000/02/14 01:35:31 version 1.20, 2000/03/10 17:13:13
Line 1 
Line 1 
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
 <html>  <html>
  <head>  <head>
   <meta http-equiv="Content-Type"  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
         content="text/html; charset=iso-8859-1">  <meta name="resource-type" content="document">
   <meta name="resource-type"  <meta name="description" CONTENT="How to make/update an OpenBSD port.">
         content="document">  <meta name="keywords" content="openbsd,ports">
   <meta name="description"  <meta name="distribution" content="global">
         CONTENT="How to make an OpenBSD port; porting checklist">  <meta name="copyright" content="This document copyright 1998 by OpenBSD.">
   <meta name="keywords"  
         content="openbsd,ports">  <title>OpenBSD Porting Checklist</title>
   <meta name="distribution"  
         content="global">  
   <meta name="copyright"  
         content="This document copyright 1998 by the OpenBSD project">  
   <title>OpenBSD Porting Checklist</title>  
   <link rev="made" HREF="mailto:www@openbsd.org">  
  </head>   </head>
  <body text="#000000" bgcolor="#FFFFFF" link="#23238E">  
   <img height=30 width=141 src=images/smalltitle.gif alt="[OpenBSD]" >  <body text="#000000" bgcolor="#FFFFFF" link="#23238E">
   <img height=30 width=141 src=images/smalltitle.gif alt="[OpenBSD]" >
   
   <h2><font color="#e00000">OpenBSD Porting Checklist</font></h2>  <h2><font color="#e00000">OpenBSD Porting Checklist</font></h2>
   
   I use this checklist as a reminder of things to do when creating  This document describes how to make or upgrade a port.  It is a useful
   new ports and when validating old ports.  I don't claim this list  reminder of things to do.  This is not totally accurate nor perfect.
   is totally accurate, much less perfect, but only hope that some  Direct comments and questions to <a href="mailto:turan@openbsd.org">
   find it useful. Direct any questions and/or comments to me at  turan@openbsd.org </a>.
   <a href="mailto:marc@snafu.org">marc@snafu.org</a>.  
   <p>  
   <ol>  
    <li>To avoid duplication, subscribe to the ports@openbsd.org  
    mailing list - somebody may be already working on the same port as you.  
    <p>  
    <li>Create Makefile -- start with the provided Makefile template  
        <code>/usr/ports/infrastructure/templates/Makefile.template</code>.  
                  This file can be retrieved from any of the anoncvs servers or via the  
        OpenBSD cvs/web source browser system  
        <a href="http://www.openbsd.org/cgi-bin/cvsweb/">http://www.openbsd.org/cgi-bin/cvsweb/</a>.  
    <p>  
    <li><code>make fetch-all</code><br>  
        This verifies that the master site, distname, and extract suffix are  
        correct. This should fetch <strong>all</strong> files needed for  
                  that port, not only those corresponding to current option or the  
                  current architecture.  
    <p>  
    <li><code>make makesum</code><br>  
        This creates the files directory and the md5 checksum for the  
        fetched files.  
    <p>  
    <li><code>make extract</code><br>  
        Ensures that the file can be extracted into the work directory.  
        This also verifies that the checksum created in step 4 is good.  
    <p>  
    <li>Create initial patches<br>  
        When the extract is complete cd to the work directory and read  
        any install docs.  You may need to modify the WRKDIST variable  
        in the makefile as well as generate initial patches to configure  
        for OpenBSD.  
     <p>Note: Patches go in the directory `patches' and are named patch-xx  
        where xx should be aa, ab, ..., az, ba, bb ... zz.  
        <ul>  
         <li>only patch one source file per patchfile, please,  
         <li>use diff -p -u to generate patches,  
         <li>all patches MUST be relative to ${WRDIST},  
         <li>check that patches <strong>DON'T</strong> contain tags that cvs  
             will replace,  
         <li>add a small explanation of the patch role in the patchfile before  
             the patch itself, and an OpenBSD CVS tag  
             <code>&#36;OpenBSD&#36;</code>.  
        </ul>  
    <p>  
    <li><code>make patch</code><br>  
        this will apply patches to the extracted sources.  If you want  
        to see the output use the command:  
     <p><code>make PATCH_DEBUG=YES patch</code>  
     <p>The easiest way to re-run patches is to `make clean &amp;&amp; make patch'.  
        This will delete the work directory and re-extract and patch.  
    <p>  
    <li>add configuration options to Makefile and/or create configuration  
        script.<br>  
        You can add a port configuration script named `configure' to a  
        directory named scripts.  This will be run before any  
        configuration specified by GNU_CONFIGURE or HAS_CONFIGURE is run.  
     <p>If GNU_CONFIGURE is used you may want to run ./configure --help  
        to see what options are available.  Anything that you may want to  
        override can be changed by adding the --option flags to the  
        CONFIGURE_ARGS parameter in the Makefile  
    <p>  
    <li>try setting <code>SEPARATE_BUILD</code><br>  
        If the port can build with object files outside its source tree,  
        this is cleaner (many programs using <code>GNU_CONFIGURE</code> can),  
        and may help people who mount their ports tree on several arches.  
        This can also spare you some effort, as you will possibly be able to  
        restart the cycle at <code>configure</code> most of the time.  
    <p>  
    <li><code>make configure</code><br>  
        Peruse the output (if any) and tweak any options in the Makefile.  
        To repeat issue the command  
        `<code>make clean &amp;&amp; make configure</code>'.  
     <p>Note: make sure host dependent files go in <code>/etc</code> or  
        <code>/etc/&lt;name&gt;</code>, but NEVER replace existing files  
        in <code>/etc</code>.  Best to have install place  
        in <code>/usr/local/lib/&lt;name&gt;</code> and then copy to  
        <code>/etc</code> or  
        <code>/etc/&lt;name&gt;</code> only if the files do not exist.  
     <p>The OpenBSD file locations are:  
   
        <pre>  <hr>
   <ol>
   
   <p><li>
   If you want to be a maintainer, subscribe to
   <a href="mailto:ports@openbsd.org"> ports@openbsd.org.</a>
   <ul><li>
   This is where all ports discussions take place.
   <li>
   Reading this list is important since many announcements go over this list.
   <li>
   You will find a lot of porting-savvy people here.  They can often give you
   good advice or test ports for you.
   </ul>
   
   <p><li>
   Check out a copy of the ports tree from cvs.
   You can find instructions to do this at
   <a href="http://www.openbsd.org/anoncvs.html">
   http://www.openbsd.org/anoncvs.html</a>.
   
   <p><li>
   Pick a place to put your port and create the basic
   infrastructure there.  Use the template Makefile at
   <code>/usr/ports/infrastructure/templates/Makefile.template</code>.
   <ul><li>
   Create the directories <code>files, patches, pkg</code>.
   <li>
   Create these empty files <code>pkg/COMMENT, pkg/DESCR, pkg/PLIST</code>
   </ul>
   
   <p><li>
   Add the fetch portions of the Makefile.
   <ul><li>
   Fill in EXTRACT_SUFFIX if its anything besides .tar.gz.  Other examples are
   .tar.Z, or .tgz.
   <li>
   Fill in DISTNAME which is the name of the file minus the extract suffix.  E.g. if you have foo-1.0.tar.gz, DISTNAME is foo-1.0.
   <li>
   Fill in MASTER_SITES which is a URL to the directory where the distfile
   is kept.  E.g. ftp://ftp.openbsd.org/pub/OpenBSD/distfiles/  <b>Don't forget
   the trailing slash.</b>  Try to have at least three distinct sites as well.
   Place the most easily accessible first as they are traversed in order.
   <li>
   Keep in mind that fetch references the file as
   ${MASTER_SITE}${DISTNAME}$EXTRACT_SUFFIX}.  All three are used.  Don't
   set DISTNAME to point to the file directly.
   <li>
   You can check to see if you have filled this values in correctly by typing
   <b>make fetch-all</b>
   </ul>
   <p>
   For more complex ports, you have more options and tools available to you:
   <ul><li>
   You also have the variable PATCHFILES available.  This is a list of vendor
   (not openbsd) patches to the port.  Common uses are things like security
   or reliability fixes.
   <li>
   If your ports are available over large public mirrors such as GNU, SunSite, or
   CPAN, we have already provided a list of sites for your use in
   /usr/ports/infrastructure/template/network.conf.template.
   Set MASTER_SITES to ${MASTER_SITE_GNU}, or ${MASTER_SITE_SUNSITE}, etc.
   To simplify this process, the construct %SUBDIR% is replaced by the variable
   MASTER_SITE_SUBDIR in your Makefile.
   <li>
   Ports normally correspond to given versions of software. Once they are retrieved, files are checksummed and compared to the recorded
   checksum in files/md5. So, to avoid confusion, DISTFILES and PATCHFILES should have clearly visible version numbers:
   don't retrieve foo-latest.tar.gz if it is a link to foo-1.0.5.tar.gz. If necessary, gently ask the original program author
   to make such distinctions clear.
   <li>
   If a given port needs more than about 5 DISTFILES + PATCHFILES to work, use DIST_SUBDIR to avoid cluttering
   /usr/ports/distfiles too much.
   <li>
   DIST_SUBDIR must not include version numbers. When the port is updated to a later version, some distfiles may not change, but will be
   refetched if DIST_SUBDIR is changed. Even if all distfiles change, it is easier for the user to track cruft.
   <li>
   All DISTFILES and PATCHFILES don't necessarily come from the same set of MASTER_SITES. Supplementary sites can be
   defined using the variables MASTER_SITES0 to MASTER_SITES9. Just write DISTFILES=foo-1.0.5.tar.gz:5 to
   retrieve foo-1.0.5.tar.gz from MASTER_SITES5.
   <li>
   Some ports don't always need to retrieve all files in all circumstances. For instance, some ports may have some compilation options, and
   associated files which are only required in such a case. Or they may need some files for some architectures only. In such a case, those
   supplementary optional files must be mentioned in the SUPDISTFILES variable. Targets such as makesum or
   mirror-distfiles will fetch those supplementary files that the casual user doesn't need.
   </ul>
   
   <p><li>
   Create a checksum in <i>files/md5</i> by typing <b>make makesum</b>.
   Then verify the checksum is correct by typing <b>make checksum</b>
   <ul><li>
   In some rare cases, files checksums can't be verified reliably. By all means, porters should try to find sites that are reliable. Communicating
   with the software author and the archive site maintainer at this stage is highly desirable. In the worst case, non-checksummable files can be
   mentioned in the IGNOREFILES variable.
   <li>
   All files in DISTFILES are usually processed during make extract. EXTRACT_ONLY may be used to limit extraction to a
   subset of files (possibly empty). The customary use of this variable is to customize extraction: for instance, if some DISTFILES need
   some special treatment, they will be removed from EXTRACT_ONLY and handled manually at post-extract stage.
   For historic reasons, make extract does set up the working directory first along with extracting files. Thus, providing a
   pre-extract or a do-extract target is highly unusual (and fairly suspicious behavior, indicative of a high degree of obfuscation
   in the port).
   <li>
   Patches that need specific treatment should be mentioned in DISTFILES, and removed from EXTRACT_ONLY, for historic reasons.
   </ul>
   
   <p><li>
   Extract the port with <b>make extract</b>.  Pay attention to where the base
   of the sources are.  Usually, its <i>work/DISTNAME</i> You may need to modify
   the Makefile's WRKDIST variable if it is different.
   
   <p><li>
   Read the installation documentation and note what you have to do to build
   the port and any special options that might be needed.
   <p><li>
   Now is also a good time to figure out what kind of licensing restrictions
   apply to your port.  Many are freely redistribution but then again, quite
   a few are not.  We need four questions answered to distribute ports
   properly.  These are the PERMIT_* values in the Makefile.
   <ul><li>
   PERMIT_PACKAGE_CDROM tells us if we can put the package on the cdrom.
   <li>
   PERMIT_PACKAGE_FTP tells us if we can put the package on the ftp sites.
   <li>
   PERMIT_DISTFILES_CDROM tells us if we can mirror the distfiles on the cdrom.
   <li>
   PERMIT_DISTFILES_FTP tells us if we can mirror the distfiles on the ftp sites.
   </ul><p>
   Set these values to Yes if it is permitted or to a comment string stating why
   it is not.  Pay attention to any special conditions you may need to fulfill
   later on.  E.g. some ports require to install a copy of the license.  We
   recommend you place the license in <code>/usr/local/share/DISTNAME/</code>.
   
   <p><li>
   Add configuration options to Makefile and/or create the configuration script.
   <ul><li>
   You can add a port configuration script named `configure' to a directory
   named <code>scripts/</code>. This will be run before any configuration
   specified by GNU_CONFIGURE or HAS_CONFIGURE is run.
   <li>
   If GNU_CONFIGURE is used you may want to run ./configure --help
   to see what options are available.
   <li>
   Anything that you may want to override can be changed by adding the
   --option flags to the CONFIGURE_ARGS parameter in the Makefile.
   <li>
   Use CONFIGURE_ARGS+= to append to the variable.  CONFIGURE_ARGS= will
   overwrite it.
   </ul>
   
   <p><li>
   Try building the port with <b>make build</b>.
   <ul><li>
   If you're lucky, the port will go all the way through without errors.
   <li>
   If it exits with an error, you will need to generate patches for your port.
   Figure out what needs to be changed and make patch for it.
   <li>
   Patches must be relative to ${WRKDIST}.
   <li> The easiest way to reset the port and test your patches is
   <b>make clean patch</b>. This will delete the work directory, re-extract,
   and patch your port.
   </ul>
   
   <p><li>
   Begin and cycle of <b>make build</b>, generate a patch, and
   <b>make clean patch</b>.
   <ul><li>
   Patches go in the directory <i>patches/</i> and should be named patch-* with
   * being something meaningful.  We recommend you name your patches
   patch-FILENAME where FILENAME is the name of the file it is patching.
   <li>
   Applying PATCHFILES is the first half of the make patch stage. It can be
   invoked separately as make distpatch, which is a convenient target for
   porters. Ignore this if you haven't set it.
   <li>
   Only patch one source file per patchfile, please,
   <li>
   Use <b>diff -p -u</b> to generate patches,
   <li>
   All patches MUST be relative to ${WRKDIST},
   <li>
   Check that patches <strong>DON'T</strong> contain tags that cvs
   will replace.  If they do, your patches won't apply after you check
   them in.  You can check in your changes with -kk to avoid this.
   <li>
   Add a small explanation of the patch role in the patchfile before
   the patch itself, and an OpenBSD CVS tag <code>&#36;OpenBSD&#36;</code>.
   <li>
   <b>Please</b> feed your patches back to the author of that piece of software.
   </ul>
   
   <p><li>
   Try setting <code>SEPARATE_BUILD</code><br>
   <ul><li>
   If the port can build with object files outside its source tree,
   this is cleaner (many programs using <code>GNU_CONFIGURE</code> can),
   and may help people who mount their ports tree on several arches.
   <li>
   This can also spare you some effort, as you will possibly be able to
   restart the cycle at <code>configure</code> most of the time.
   </ul>
   
   <p><li>
   Peruse the output (if any) and tweak any options in the Makefile.
   To repeat issue the command `<b>make clean configure</b>'.
   <p>
   Note: make sure host dependent files go in <i>/etc</i> or
   <i>/etc/&lt;name&gt;</i>, but <b>NEVER REPLACE OR MODIFY</b> existing files
   in <i>/etc</i>.  Best to have install place
   in <i>/usr/local/share/&lt;name&gt;</i> and then copy to
   <i>/etc</i> or <i>/etc/&lt;name&gt;</i> only if the files do not exist.
   If the files exist, display a message that says such-and-such files need
   to be modified.  This also guarantees that the files will be included in
   the package since everything under <i>/usr/local</i> is included in the PLIST
   
   <p>
   The OpenBSD file locations are:
   <pre>
    user executables:                    /usr/local/bin     user executables:                    /usr/local/bin
    system admin executables:            /usr/local/sbin     system admin executables:            /usr/local/sbin
    program executables:                 /usr/local/libexec     program executables:                 /usr/local/libexec
Line 119 
Line 251 
    man pages:                           /usr/local/man/...     man pages:                           /usr/local/man/...
    read-only architecture-independent:  /usr/local/share/&lt;name&gt;     read-only architecture-independent:  /usr/local/share/&lt;name&gt;
    misc documentation:                  /usr/local/share/doc/&lt;name&gt;     misc documentation:                  /usr/local/share/doc/&lt;name&gt;
        </pre>  </pre>
   
    <p>  <p><li>
    <li><code>make</code><br>  Begin a cycle of makes until the port is ready.  Patch (see above)
        Begin a cycle of makes until the port is ready.  Patch (see above)  clean, and make until the port is generated.  Get rid of all warnings
        clean, and make until the port is generated.  Get rid of all warnings  if possible, especially security related warnings.
        if possible, especially security related warnings.  <p><li>
    <p>  Control SEPARATE_BUILD semantics.
    <li>Control <code>SEPARATE_BUILD</code> semantics<br>  You have to do this only if the port builds with
        You have to do this only if the port builds with  SEPARATE_BUILD defined.
        <code>SEPARATE_BUILD</code> defined.  Ideally, the port should no longer modify any file in
        Ideally, the port should no longer modify any file in  ${WRKSRC} after <b>make patch</b>.
        <code>${WRKSRC}</code> after <code>make patch</code>.  You can check this by making sure you don't have any write access
        You can check this by making sure you don't have any write access  to ${WRKSRC}. Then you can set
        to <code>${WRKSRC}</code>. Then you can set  SEPARATE_BUILD=concurrent: someone can use the same
        <code>SEPARATE_BUILD=concurrent</code>: someone can use the same  source tree to build on distinct arches simultaneously.
        source tree to build on distinct arches simultaneously.  Otherwise, set <code>SEPARATE_BUILD=simple</code>: building on
        Otherwise, set <code>SEPARATE_BUILD=simple</code>: building on  distinct arches simultaneously may meet with problems, as some
        distinct arches simultaneously may meet with problems, as some  source files may be regenerated at awkward moments.
        source files may be regenerated at awkward moments.  
    <p>  
    <li><code>mkdir pkg; touch pkg/{DESCR,COMMENT,PLIST}</code><br>  
         Create dummy versions of the package files.  Edit DESCR and COMMENT.  
      <p>COMMENT is a <strong>SHORT</strong> one-line description of the port  
      (max. 60 characters). Do NOT include the package name (or version number  
      of the software) in the comment. Do NOT start with an uppercase letter  
      unless semantically significant, do NOT end with a period.  
      <p>DESCR is a longer description of the port. One to a few paragraphs  
         concisely explaining what the port does is sufficient.  
      <p>PLIST is kept empty at this point.  
    <p>  
    <li><code>sudo make install</code><br>  
        install the application.  
    <p>  
         <li>If the port installs dynamic libraries, check their symbol tables  
         with <code>nm</code>, as some mistaken software strips dynamic libraries,  
         which may lead to weird failures later.  
         <p>  
         <li><strong>Check port for security holes again</strong>. This is  
                 especially important for network and setuid programs. See  
                 <a href="porting.html#security">our security recommendations</a>  
                 for that. Log interesting stuff and fixes in the  
                 <code>pkg/SECURITY</code> file.  This file  
                 should list audited potential problems, along with relevant patches,  
                 so that another person can see at first glance what has been done.  
                 Example:  
   
   <p><li>
   Edit <i>pkg/DESCR</i>, <i>pkg/COMMENT</i>, <i>pkg/PLIST</i>.
   <ul>
   <li>
   COMMENT is a <strong>SHORT</strong> one-line description of the port
   (max. 60 characters). Do NOT include the package name (or version number
   of the software) in the comment. Do NOT start with an uppercase letter
   unless semantically significant, do NOT end with a period.
   <li>
   DESCR is a longer description of the port. One to a few paragraphs
   concisely explaining what the port does is sufficient.
   <li>
   PLIST is kept empty at this point.
   </ul>
   
   <p><li>
   Install the application with <b>make install</b>
   <p>
   If the port installs dynamic libraries, check their symbol tables
   with <code>nm</code>, as some mistaken software strips dynamic libraries,
   which may lead to weird failures later.
   
   <p><li>
   <strong>Check port for security holes again</strong>. This is
   especially important for network and setuid programs. See
   <a href="porting.html#security">our security recommendations</a>
   for that. Log interesting stuff and fixes in the
   <code>pkg/SECURITY</code> file.  This file
   should list audited potential problems, along with relevant patches,
   so that another person can see at first glance what has been done.
   Example:
 <pre>  <pre>
       &#36;OpenBSD&#36;        &#36;OpenBSD&#36;
   
Line 173 
Line 309 
          call to mktemp (wrapper function do_mktemp) does seem to be correct.           call to mktemp (wrapper function do_mktemp) does seem to be correct.
   
       The server makes extensive use of strlcpy/strlcat/snprintf.        The server makes extensive use of strlcpy/strlcat/snprintf.
   
 </pre>  </pre>
   
    <li>Create pkg/PLIST<br>  <p><li>
        After the install is complete use the developer's command:  Create pkg/PLIST.  After the install is complete use the developer's command,
     <p><code>make plist</code>  <b>make plist</b> which makes the file PLIST-auto in the <i>pkg</i> directory.
     <p>which makes the file PLIST-auto in the pkg directory.  This file  This file is a candidate packing list.
        is a candidate packing list.  Beware: the files are found by  <p>
        timestamp.  This means it does NOT:  Beware! The files are found by timestamp.  This means it does NOT:
        <ul>  <ul>
         <li>list any files installed with `tar' as their timestamp  <li>
             will not change and thus won't be found by `find'  list any files installed with `tar' as their timestamp
         <li>update the <code>info/dir</code> file if .info files are  will not change and thus won't be found by `find'
             added.  You'll have to add that by hand.  Also, be sure that  <li>
             the <code>info/dir</code> is not part of the PLIST.  Update the <code>info/dir</code> file if .info files are added.
         <li>try to do anything special with links or symbolic links.  A  Also, be sure that the <code>info/dir</code> is not part of the PLIST.
             cursory test of tar shows it does the right thing with links  <li>
             and symbolic links so I don't see why we need to special case  Try to do anything special with links or symbolic links.  A
             anything in the packing list.  But still...  cursory test of tar shows it does the right thing with links
        </ul>  and symbolic links so I don't see why we need to special case
      <p>Peruse `PLIST-auto' and verify that everything was installed and  anything in the packing list.  But still...
         that it was installed in the proper locations.  Anything not installed  </ul>
         can be added to a port Makefile `post-install' rule.  <p>
      <p>Copy `PLIST-auto' to `PLIST'  Peruse `PLIST-auto' and verify that everything was installed and
      <p>Ports that install shared libraries will need two versions of  that it was installed in the proper locations.  Anything not installed
         the PLIST file.  <code>PLIST</code> describes the files installed on  can be added to a port Makefile `post-install' rule.
         those architectures that support shared libraries, and  <p>
         <code>PLIST.noshared</code> describes the files installed on  Move `PLIST-auto' to `PLIST'
         architectures that do not support shared libs.  Typically,  
         <code>PLIST.noshared</code> is a copy of <code>PLIST</code>  <p>
         less references to any shared libraries.  Ports that install shared libraries will need two versions of the PLIST file.
    <p>  <ul>
    <li>uninstall and reinstall; repeat until perfect.<br>  <li>
        <em>Perfect</em> is when everything installs and uninstalls  PLIST describes the files installed on those architectures that support
        in its proper location.  `<code>pkg_delete &lt;pkg_name&gt;</code>' is  shared libraries.
        used to uninstall.  `sudo make reinstall' is used to reinstall.  See the  <li>
        `<code>pkg_create</code>' man page for other commands that may be added  PLIST.noshared describes the files installed on architectures that do not
        to PLIST to ensure all is cleaned up.  After an uninstall the command  support shared libs.
        <p><code>find /usr/local -newer work/.install_started -print</code>  <li>
        <p>should only list standard directory names.  Typically, PLIST.noshared is a copy of PLIST less references to any
    <p>  shared libraries.
    <li>Create package:<br>  </ul>
        After the port installs correctly issue the command  
        <code>make package</code> to create a package.  To test the  <p><li>
        package first do a <code>pkg_delete</code> and then do a  Keep repeating uninstall and reinstall until perfect.<br>
        <code>pkg_add</code>   The results after an add should EXACTLY  <em>Perfect</em> is when everything installs and uninstalls
        match the results after a `make install'.  in its proper location.  `pkg_delete &lt;pkg_name&gt;' is
    <p>  used to uninstall.  `sudo make reinstall' is used to reinstall.  See the
         <li>Distribute it!<br>  `pkg_create' man page for other commands that may be added
         Since the whole point of this process  to PLIST to ensure all is cleaned up.  After an uninstall the command
         is to make your ported version of the software available to  <p><code>find /usr/local -newer work/.install_started -print</code>
         other OpenBSD users, you now need to disseminate it.  <p>should only list standard directory names.
         <ul>  
             <li>First, get others to test it on a variety of  <p><li>
                 platforms (the DEC Alpha is good  because it has only static libraries  Test the packaging:<br>
                 and because sizeof int != sizeof long; Sun SPARC is good because it is  After the port installs correctly issue the command
                 very common and because its byte order is the reverse of i386; if you  <code>make package</code> to create a package.  To test the
                 developed on SPARC, of course, you'd want it tested on i386).  package first do a <code>pkg_delete</code> and then do a
                 <P>The ports@openbsd mailing list is a good place to find porting-savy  <code>pkg_add</code>   The results after an add should EXACTLY
                 people with different platforms!  match the results after a `make install'.
                 <li>Incorporate any feedback you get. Test it again on your platform.  
                 Get those who gave you feedback to test it again from your new port.  <p><li>
                 <li>Finally, include it in the "ports" tree.  Mail <a href="mailto:ports@openbsd.org">ports@openbsd.org</a> with a short
                 If you are a developer with CVS access, check it in.  note asking for comments and testing.  Attach the port to this email and
                 We normally use "import" for a new port,  sent it out.  If you don't get any comments, send email to
                 rather than adding a zillion (or a dozen) files individually.  <a href="turan@openbsd.org">turan@openbsd.org</a> and I will pick it for you.
                 Import uses "vendor branch" version numbers like 1.1.1.1, but don't worry  <p>
                 about that! :-) If you make changes to a specific file (edit, then  Try to get others to test it on a variety of platforms for you.
                 cvs commit), it will be 1.2, and that will be used.  <ul><li>
                 <P>  The DEC Alpha is good  because it has only static libraries and because
                 In short, import is typically used when a port is created.  sizeof(int) != sizeof(long)
                 From that point on cvs add and cvs rm are typically used to add or remove  <li>
                 files, and the normal edit->commit cycle for changes.  Sun SPARC is good because it is very common and because its byte order is
                 <P>  the reverse of i386; if you developed on SPARC, of course, you'd want it
                 You might use something like this:  tested on i386).
                 <pre>  <p>
   </ul>
   
   <p><li>
   Incorporate any feedback you get. Test it again on your platform.
   Get those who gave you feedback to test it again from your new port.
   
   <p><li>
   Finally, include it in the "ports" tree.
   <p>
   If you do not have CVS access, ask someone on
   <a href="ports@openbsd.org">ports@openbsd.org</a> to commit it.  Don't forget
   about me, <a href="turan@openbsd.org">turan@openbsd.org</a> if no one
   picks it up.
   
   <p><li>
   If you are a developer with CVS access, check it in.
   We normally use "import" for a new port,
   rather than adding a zillion (or a dozen) files individually.
   Import uses "vendor branch" version numbers like 1.1.1.1, but don't worry
   about that! :-) If you make changes to a specific file (edit, then
   cvs commit), it will be 1.2, and that will be used.
   <p>
   In short, import is typically used when a port is created.
   From that point on cvs add and cvs rm are typically used to add or remove
   files, and the normal edit->commit cycle for changes.
   You might use something like this:
   <pre>
 cd kaffe1  cd kaffe1
 make clean      # you really really don't want to check in all of work!  make clean      # you really really don't want to check in all of work!
 cvs -d cvs.openbsd.org:/cvs import -m 'kaffe port' ports/lang/kaffe1 \  cvs -d cvs.openbsd.org:/cvs import -m 'kaffe port' ports/lang/kaffe1 \
         <I>YourName</I> <I>YourName_YYYY-MMM-DD</I>          <I>YourName</I> <I>YourName_YYYY-MMM-DD</I>
                 </pre>  </pre>
                 <P>-d cvs.openbsd.org:/cvs says where cvs lives. This can be omitted if you  <ul><li>
                 have a CVS_ROOT environment variable defined.  -d cvs.openbsd.org:/cvs says where cvs lives. This can be omitted if you
                 <P>-m 'kaffe port' is your login message.  Change it to whatever you like  have a CVS_ROOT environment variable defined.
                 <P>ports/lang/kaffe1 is the path relative to /cvs where the port lives  <li>
                 <P><I>YourName</I> (replaced with your login name) is the "vendor tag".  -m 'kaffe port' is your login message.  Change it to whatever you like
                 You imported it so you are the vendor.  <li>
                 <P><I>YourName_YYYY-MMM-DD</I> (e.g., ian_2000-Jan-01)  ports/lang/kaffe1 is the path relative to /cvs where the port lives
                 is the 'vendor release tag'.  This is as good as any.  <li>
                 <P>As a real example, here is the output of checking in the Kaffe1 port,  <i>YourName</i> (replaced with your login name) is the "vendor tag".
                 which one of us did on September 8, 1998:  You imported it so you are the vendor.
                 <pre>  <li>
   <i>YourName_YYYY-MMM-DD</i> (e.g., ian_2000-Jan-01)
   is the 'vendor release tag'.  This is as good as any.
   </ul>
   As a real example, here is the output of checking in the Kaffe1 port,
   which one of us did on September 8, 1998:
   <pre>
 $ cd kaffe1  $ cd kaffe1
 $ make clean >/dev/null  $ make clean >/dev/null
 $ cvs import -m 'kaffe1.0(==JDK1.1) port' ports/lang/kaffe1 ian ian_1998-Sep-08  $ cvs import -m 'kaffe1.0(==JDK1.1) port' ports/lang/kaffe1 ian ian_1998-Sep-08
Line 282 
Line 450 
   
 No conflicts created by this import  No conflicts created by this import
 $  $
                 </pre>  </pre>
                 <P>Last but not least, add a one-line entry for the new port  
                 in its parent directory's makefile, i.e., for ports/lang/kaffe1,  <p><li>
                 add it to ports/lang/Makefile.  Last but not least, add a one-line entry for the new port
                 <P>If you do not have CVS commit access, send mail to the ports  in its parent directory's makefile, i.e., for ports/lang/kaffe1,
                 maintainers at ports@openbsd.org,  add it to ports/lang/Makefile.
                 stating that you have a port ready to go into the tree. List the  
                 name and version of the program, the platforms it's been tested on,  <p><li>
                 and any limitations.  Maintain the port!  As time goes by, problems may arise, or new versions
         </UL>  of the software may be released. You should strive to keep your port up
   <P>  to date.  In other words - iterate, test, test, iterate, ...
   <LI>Maintain the port!<BR>  </ul>
   As time goes by, problems may arise, or new versions of the software  
   may be released. You should strive to keep your port up to date.  Thank you for supporting the OpenBSD "ports" process!
   In other words - iterate, test, test, iterate, ...  <hr>
   </ol>  <a href="porting.html"><img height=24 width=24 src=back.gif
   Thank you for supporting the OpenBSD "ports" process!   border=0 alt=Porting></a>
   <hr>  <a href="mailto:www@openbsd.org">www@openbsd.org</a>
   <a href="porting.html"><img height=24 width=24 src=back.gif  <br><small>$OpenBSD$</small>
    border=0 alt=Porting></a>  </body>
   <a href="mailto:www@openbsd.org">www@openbsd.org</a>  
   <br><small>$OpenBSD$</small>  
  </body>  
 </html>  </html>
Legend:
Removed from v.1.19  
changed lines
  Added in v.1.20