Annotation of www/checklist.html, Revision 1.66
1.14 rohee 1: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
1.1 marc 2: <html>
1.20 turan 3: <head>
4: <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
5: <meta name="resource-type" content="document">
6: <meta name="description" CONTENT="How to make/update an OpenBSD port.">
7: <meta name="keywords" content="openbsd,ports">
8: <meta name="distribution" content="global">
1.64 jsg 9: <meta name="copyright" content="This document copyright 1998-2007 by OpenBSD.">
1.20 turan 10:
11: <title>OpenBSD Porting Checklist</title>
1.45 jsyn 12: </head>
1.20 turan 13:
1.53 jose 14: <body text="#000000" bgcolor="#FFFFFF" link="#23238E">
1.43 jsyn 15: <a href="index.html"><img alt="[OpenBSD]" height="30" width="141" src="images/smalltitle.gif" border="0"></a>
1.20 turan 16:
17: <h2><font color="#e00000">OpenBSD Porting Checklist</font></h2>
18:
19: This document describes how to make or upgrade a port. It is a useful
1.33 pvalchev 20: reminder of things to do. This is neither totally accurate nor perfect.
1.45 jsyn 21: Direct comments and questions to <a href="mailto:ports@openbsd.org">
22: ports@openbsd.org</a>.
1.20 turan 23:
24: <hr>
25: <ol>
26:
1.22 rohee 27: <li>
1.20 turan 28: If you want to be a maintainer, subscribe to
1.53 jose 29: <a href="mailto:ports@openbsd.org">ports@openbsd.org.</a>
1.20 turan 30: <ul><li>
31: This is where all ports discussions take place.
32: <li>
33: Reading this list is important since many announcements go over this list.
34: <li>
1.33 pvalchev 35: You will find a lot of porting-savvy people there. They can often give you
1.20 turan 36: good advice or test ports for you.
37: </ul>
38:
1.22 rohee 39: <br><li>
1.29 espie 40: Being a maintainer means <strong>more</strong> than just submitting ports.
41: It also means trying to keep them up-to-date, and to answer questions about
42: them.
43:
1.45 jsyn 44: <br><br><li>
1.20 turan 45: Check out a copy of the ports tree from cvs.
1.59 jcs 46: You can find instructions on how to do this at the
47: <a href="anoncvs.html">anonymous cvs page</a>.
1.20 turan 48:
1.22 rohee 49: <br><br><li>
1.20 turan 50: Pick a place to put your port and create the basic
51: infrastructure there. Use the template Makefile at
52: <code>/usr/ports/infrastructure/templates/Makefile.template</code>.
1.44 pvalchev 53: NEED_VERSION is obsolete and should not be used in new ports.
54: As you are a port developer, you are supposed to update
55: your ports tree, including bsd.port.mk.
1.20 turan 56: <ul><li>
1.49 cannings 57: Create the directory <code>pkg</code>.
1.20 turan 58: <li>
1.45 jsyn 59: Create the empty files <code>pkg/DESCR, pkg/PLIST</code>.
1.20 turan 60: </ul>
61:
1.22 rohee 62: <br><li>
1.20 turan 63: Add the fetch portions of the Makefile.
64: <ul><li>
1.37 pvalchev 65: Fill in EXTRACT_SUFX if it's anything besides .tar.gz. Other examples are
1.20 turan 66: .tar.Z, or .tgz.
67: <li>
1.45 jsyn 68: Fill in DISTNAME which is the name of the file minus the extract suffix.
69: E.g., if you have foo-1.0.tar.gz, DISTNAME is foo-1.0.
1.20 turan 70: <li>
71: Fill in MASTER_SITES which is a URL to the directory where the distfile
1.45 jsyn 72: is kept. E.g., ftp://ftp.openbsd.org/pub/OpenBSD/distfiles/.
73: <strong>Don't forget the trailing slash.</strong>
74: Try to have at least three distinct sites as well.
1.20 turan 75: Place the most easily accessible first as they are traversed in order.
76: <li>
77: Keep in mind that fetch references the file as
1.32 naddy 78: ${MASTER_SITES}${DISTNAME}${EXTRACT_SUFX}. All three are used. Don't
1.20 turan 79: set DISTNAME to point to the file directly.
80: <li>
1.33 pvalchev 81: You can check to see if you have filled these values in correctly by typing
1.45 jsyn 82: <b>make fetch-all</b>.
1.20 turan 83: </ul>
84: <p>
85: For more complex ports, you have more options and tools available to you:
86: <ul><li>
87: You also have the variable PATCHFILES available. This is a list of vendor
1.22 rohee 88: (not OpenBSD) patches to the port. Common uses are things like security
1.20 turan 89: or reliability fixes.
90: <li>
91: If your ports are available over large public mirrors such as GNU, SunSite, or
92: CPAN, we have already provided a list of sites for your use in
1.48 david 93: /usr/ports/infrastructure/templates/network.conf.template.
1.20 turan 94: Set MASTER_SITES to ${MASTER_SITE_GNU}, or ${MASTER_SITE_SUNSITE}, etc.
1.42 pvalchev 95: To simplify this process, use the construct ${MASTER_SITE_FOO:=subdir/} to
96: append the distribution subdirectory.
1.20 turan 97: <li>
98: Ports normally correspond to given versions of software. Once they are retrieved, files are checksummed and compared to the recorded
1.40 naddy 99: checksum(s) in distinfo. So, to avoid confusion, DISTFILES and PATCHFILES should have clearly visible version numbers:
1.20 turan 100: 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
101: to make such distinctions clear.
102: <li>
103: If a given port needs more than about 5 DISTFILES + PATCHFILES to work, use DIST_SUBDIR to avoid cluttering
104: /usr/ports/distfiles too much.
105: <li>
106: DIST_SUBDIR must not include version numbers. When the port is updated to a later version, some distfiles may not change, but will be
107: refetched if DIST_SUBDIR is changed. Even if all distfiles change, it is easier for the user to track cruft.
108: <li>
109: All DISTFILES and PATCHFILES don't necessarily come from the same set of MASTER_SITES. Supplementary sites can be
110: defined using the variables MASTER_SITES0 to MASTER_SITES9. Just write DISTFILES=foo-1.0.5.tar.gz:5 to
111: retrieve foo-1.0.5.tar.gz from MASTER_SITES5.
112: <li>
113: Some ports don't always need to retrieve all files in all circumstances. For instance, some ports may have some compilation options, and
114: 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
115: supplementary optional files must be mentioned in the SUPDISTFILES variable. Targets such as makesum or
116: mirror-distfiles will fetch those supplementary files that the casual user doesn't need.
117: </ul>
1.1 marc 118:
1.22 rohee 119: <br><li>
1.40 naddy 120: Create a checksum in <i>distinfo</i> by typing <b>make makesum</b>.
1.45 jsyn 121: Then verify the checksum is correct by typing <b>make checksum</b>.
1.20 turan 122: <ul><li>
123: In some rare cases, files checksums can't be verified reliably. By all means, porters should try to find sites that are reliable. Communicating
124: with the software author and the archive site maintainer at this stage is highly desirable. In the worst case, non-checksummable files can be
125: mentioned in the IGNOREFILES variable.
126: <li>
127: All files in DISTFILES are usually processed during make extract. EXTRACT_ONLY may be used to limit extraction to a
128: subset of files (possibly empty). The customary use of this variable is to customize extraction: for instance, if some DISTFILES need
129: some special treatment, they will be removed from EXTRACT_ONLY and handled manually at post-extract stage.
130: For historic reasons, make extract does set up the working directory first along with extracting files. Thus, providing a
131: pre-extract or a do-extract target is highly unusual (and fairly suspicious behavior, indicative of a high degree of obfuscation
132: in the port).
133: <li>
134: Patches that need specific treatment should be mentioned in DISTFILES, and removed from EXTRACT_ONLY, for historic reasons.
135: </ul>
1.1 marc 136:
1.22 rohee 137: <br><li>
1.20 turan 138: Extract the port with <b>make extract</b>. Pay attention to where the base
1.38 pvalchev 139: of the sources are. Usually, it's <i>w-${PKGNAME}${FLAVOR_EXT}/${DISTNAME}</i>. You may need to
140: modify the Makefile's WRKDIST variable if it is different.
1.9 espie 141:
1.22 rohee 142: <br><br><li>
1.20 turan 143: Read the installation documentation and note what you have to do to build
144: the port and any special options that might be needed.
1.22 rohee 145:
146: <br><br><li>
1.20 turan 147: Now is also a good time to figure out what kind of licensing restrictions
1.33 pvalchev 148: apply to your port. Many are freely redistributable but then again, quite
1.20 turan 149: a few are not. We need four questions answered to distribute ports
150: properly. These are the PERMIT_* values in the Makefile.
151: <ul><li>
152: PERMIT_PACKAGE_CDROM tells us if we can put the package on the cdrom.
153: <li>
154: PERMIT_PACKAGE_FTP tells us if we can put the package on the ftp sites.
155: <li>
156: PERMIT_DISTFILES_CDROM tells us if we can mirror the distfiles on the cdrom.
157: <li>
158: PERMIT_DISTFILES_FTP tells us if we can mirror the distfiles on the ftp sites.
1.45 jsyn 159: </ul>
160: <p>
1.20 turan 161: Set these values to Yes if it is permitted or to a comment string stating why
162: it is not. Pay attention to any special conditions you may need to fulfill
1.45 jsyn 163: later on. E.g., some ports require to install a copy of the license. We
1.57 xsa 164: recommend you place the license in
165: <code>/usr/local/share/doc/<name>/</code>.
166: <p>
167: In addition to the PERMIT_* values, put a license marker like
168: <code># License</code> above them as a comment, this way we know why
169: the PERMIT_* values are set the way they are.
1.20 turan 170:
1.22 rohee 171: <br><br><li>
1.20 turan 172: Add configuration options to Makefile and/or create the configuration script.
173: <ul><li>
174: You can add a port configuration script named `configure' to a directory
175: named <code>scripts/</code>. This will be run before any configuration
1.40 naddy 176: specified by CONFIGURE_STYLE is run.
1.20 turan 177: <li>
1.40 naddy 178: If GNU configure is used you may want to run ./configure --help
1.20 turan 179: to see what options are available.
180: <li>
181: Anything that you may want to override can be changed by adding the
182: --option flags to the CONFIGURE_ARGS parameter in the Makefile.
183: <li>
184: Use CONFIGURE_ARGS+= to append to the variable. CONFIGURE_ARGS= will
185: overwrite it.
186: </ul>
187:
1.22 rohee 188: <br><li>
1.20 turan 189: Try building the port with <b>make build</b>.
190: <ul><li>
191: If you're lucky, the port will go all the way through without errors.
192: <li>
193: If it exits with an error, you will need to generate patches for your port.
1.33 pvalchev 194: Figure out what needs to be changed and make a patch for it.
1.20 turan 195: <li>
196: Patches must be relative to ${WRKDIST}.
197: <li> The easiest way to reset the port and test your patches is
198: <b>make clean patch</b>. This will delete the work directory, re-extract,
199: and patch your port.
200: </ul>
201:
1.22 rohee 202: <br><li>
1.63 joel 203: Begin a cycle of <b>make build</b>, generate a patch (or use <b>make
1.26 reinhard 204: update-patches</b>), and
1.20 turan 205: <b>make clean patch</b>.
206: <ul><li>
207: Patches go in the directory <i>patches/</i> and should be named patch-* with
208: * being something meaningful. We recommend you name your patches
1.26 reinhard 209: patch-FILENAME where FILENAME is the name of the file it is patching.
210: (<tt>make update-patches</tt> does this automatically for you.)
1.20 turan 211: <li>
212: Applying PATCHFILES is the first half of the make patch stage. It can be
213: invoked separately as make distpatch, which is a convenient target for
214: porters. Ignore this if you haven't set it.
215: <li>
1.52 margarid 216: Only patch one source file per patchfile, please.
1.20 turan 217: <li>
1.52 margarid 218: Use <b>make update-patches</b> to generate patches.
1.20 turan 219: <li>
1.52 margarid 220: All patches MUST be relative to ${WRKDIST}.
1.20 turan 221: <li>
222: Check that patches <strong>DON'T</strong> contain tags that cvs
223: will replace. If they do, your patches won't apply after you check
224: them in. You can check in your changes with -kk to avoid this.
225: <li>
1.52 margarid 226: Write a small explanation at the beginning of the patchfile about its purpose
227: (not mandatory).
1.20 turan 228: <li>
229: <b>Please</b> feed your patches back to the author of that piece of software.
230: </ul>
231:
1.22 rohee 232: <br><li>
1.45 jsyn 233: Try setting <code>SEPARATE_BUILD</code>.
1.20 turan 234: <ul><li>
235: If the port can build with object files outside its source tree,
1.40 naddy 236: this is cleaner (many programs using <code>CONFIGURE_STYLE=gnu</code> can),
1.20 turan 237: and may help people who mount their ports tree on several arches.
238: <li>
239: This can also spare you some effort, as you will possibly be able to
240: restart the cycle at <code>configure</code> most of the time.
241: </ul>
242:
1.22 rohee 243: <br><li>
1.20 turan 244: Peruse the output (if any) and tweak any options in the Makefile.
245: To repeat issue the command `<b>make clean configure</b>'.
246: <p>
1.45 jsyn 247: Note: make sure host-dependent files go in <i>/etc</i> or
248: <i>/etc/<name></i>, but <strong>NEVER REPLACE OR MODIFY</strong>
249: existing files in <i>/etc</i>. Best to have install place them
1.20 turan 250: in <i>/usr/local/share/<name></i> and then copy to
251: <i>/etc</i> or <i>/etc/<name></i> only if the files do not exist.
252: If the files exist, display a message that says such-and-such files need
253: to be modified. This also guarantees that the files will be included in
1.40 naddy 254: the package since everything under <i>/usr/local</i> is included in the PLIST.
255: After a package has been installed the contents of <code>pkg/MESSAGE</code>
256: will be displayed if it exists.
1.20 turan 257:
258: <p>
259: The OpenBSD file locations are:
260: <pre>
1.1 marc 261: user executables: /usr/local/bin
262: system admin executables: /usr/local/sbin
263: program executables: /usr/local/libexec
1.56 xsa 264: libraries: /usr/local/lib
265: architecture dependent data: /usr/local/lib/<name>
1.1 marc 266: installed include files: /usr/local/include or
1.14 rohee 267: /usr/local/include/<name>
268: single-machine data: /etc or /etc/<name>
1.1 marc 269: local state: /var/run
1.35 brad 270: games score files: /var/games
1.1 marc 271: GNU info files: /usr/local/info
272: man pages: /usr/local/man/...
1.14 rohee 273: read-only architecture-independent: /usr/local/share/<name>
274: misc documentation: /usr/local/share/doc/<name>
1.56 xsa 275: examples files: /usr/local/share/examples/<name>
1.20 turan 276: </pre>
1.9 espie 277:
1.22 rohee 278: <li>
1.20 turan 279: Begin a cycle of makes until the port is ready. Patch (see above)
280: clean, and make until the port is generated. Get rid of all warnings
281: if possible, especially security related warnings.
1.22 rohee 282:
283: <br><br><li>
1.20 turan 284: Control SEPARATE_BUILD semantics.
285: You have to do this only if the port builds with
286: SEPARATE_BUILD defined.
1.45 jsyn 287: Ideally, the port should not modify any file in
1.20 turan 288: ${WRKSRC} after <b>make patch</b>.
289: You can check this by making sure you don't have any write access
290: to ${WRKSRC}. Then you can set
1.45 jsyn 291: <code>SEPARATE_BUILD=concurrent</code> -- someone can use the same
1.20 turan 292: source tree to build on distinct arches simultaneously.
1.45 jsyn 293: Otherwise, set <code>SEPARATE_BUILD=simple</code> -- building on
294: distinct arches simultaneously may be met with problems, as some
1.20 turan 295: source files may be regenerated at awkward moments.
1.9 espie 296:
1.22 rohee 297: <br><br><li>
1.31 reinhard 298: Add <i>COMMENT</i> in Makefile.
1.20 turan 299: COMMENT is a <strong>SHORT</strong> one-line description of the port
1.24 espie 300: (max. 60 characters). Do <strong>NOT</strong> include the package
301: name (or version number of the software) in the comment.
302: Do <strong>NOT</strong> start with an uppercase letter
1.45 jsyn 303: unless semantically significant, and
1.24 espie 304: do <strong>NOT</strong> end with a period.
1.54 jmc 305: <strong>DON'T EVER START WITH AN INDEFINITE ARTICLE SUCH AS `a' or `an';
1.24 espie 306: remove the article altogether.</strong>
1.31 reinhard 307:
308: <br><br><li>
309: Edit <i>pkg/DESCR</i>, <i>pkg/PLIST</i>.
1.45 jsyn 310: <ul><li>
1.20 turan 311: DESCR is a longer description of the port. One to a few paragraphs
1.39 jufi 312: concisely explaining what the port does is sufficient. It is also advised to
1.46 pvalchev 313: wrap your lines at 72 characters. This can be done by first editing the DESCR
314: file and then running it through 'fmt -w 72'.
1.20 turan 315: <li>
316: PLIST is kept empty at this point.
317: </ul>
318:
1.22 rohee 319: <br><li>
1.51 sturm 320: If the application needs to create a user or a group, choose the lowest free
321: id from <code>/usr/ports/infrastructure/db/user.list</code> for your port to
322: use and make sure your port gets added to this file at commit time.
323:
324: <br><br><li>
1.45 jsyn 325: Install the application with <b>make install</b>.
1.20 turan 326: If the port installs dynamic libraries, check their symbol tables
327: with <code>nm</code>, as some mistaken software strips dynamic libraries,
1.34 jsyn 328: which may lead to weird failures later. On the other hand, executable binaries
329: SHOULD be stripped; <code>file</code> can be used to determine this. If the
330: port already contains code for stripping binaries, use it (i.e., an
331: 'install-strip' target); otherwise, add a provision in the port Makefile.
1.20 turan 332:
1.22 rohee 333: <br><br><li>
1.20 turan 334: <strong>Check port for security holes again</strong>. This is
335: especially important for network and setuid programs. See
1.50 jolan 336: <a href="porting.html#Security">our security recommendations</a>
1.20 turan 337: for that. Log interesting stuff and fixes in the
338: <code>pkg/SECURITY</code> file. This file
339: should list audited potential problems, along with relevant patches,
340: so that another person can see at first glance what has been done.
341: Example:
1.14 rohee 342: <pre>
343: $OpenBSD$
1.9 espie 344:
345: ${WRKDIR}/receiver.c
346: call to mktemp (wrapper function do_mktemp) does seem to be correct.
347:
348: The server makes extensive use of strlcpy/strlcat/snprintf.
1.20 turan 349: </pre>
350:
1.66 ! espie 351: <br><br><li>
! 352: Make sure your <code>/etc/mtree</code> directory is up-to-date.
! 353: (The next step uses the mtree lists to remove existing directories from
! 354: generated packing-lists). Remember that <code>(U)pdate</code> does not
! 355: touch <code>/etc</code>...
! 356: <br><br><li>
1.20 turan 357: Create pkg/PLIST. After the install is complete use the developer's command,
1.33 pvalchev 358: <b>make plist</b> which makes the file PLIST in the <i>pkg</i> directory.
1.20 turan 359: This file is a candidate packing list.
360: <p>
1.33 pvalchev 361: Peruse `PLIST' and verify that everything was installed and
1.20 turan 362: that it was installed in the proper locations. Anything not installed
363: can be added to a port Makefile `post-install' rule.
364: <p>
1.45 jsyn 365: Ports that install shared libraries will have another file called PFRAG.shared.
366: <ul><li>
1.33 pvalchev 367: PLIST describes the files being independent of whether the architecture supports shared libraries or not.
368: <li>
369: PFRAG.shared describes only the files being additionally installed on those architectures that support
1.20 turan 370: shared libraries.
371: <li>
1.33 pvalchev 372: PFRAG.noshared describes only the files being additionally installed on architectures that do not
373: support shared libraries.
1.20 turan 374: </ul>
375:
1.22 rohee 376: <br><br><li>
1.66 ! espie 377: Verify shared library dependencies. Run <code>make port-lib-depends-check</code>
! 378: and add every <code>LIB_DEPENDS</code> or <code>WANTLIB</code> annotation
! 379: that is needed until it runs cleanly.
! 380: You may want to read
! 381: <a href="porting/update.html">the update guidelines</a>
! 382: to understand why this is so important.
! 383: <br><br><li>
! 384: If you added to <code>LIB_DEPENDS</code>, Re-run <b>make plist</b>. It
! 385: is possible some directories do not need to be in the PLIST, as they've
! 386: been installed by a dependency.
! 387: <br><br><li>
1.45 jsyn 388: Test the packaging.
1.20 turan 389: After the port installs correctly issue the command
390: <code>make package</code> to create a package. To test the
1.61 espie 391: package first do a <code>pkg_add</code> and then do a
392: <code>pkg_delete</code>
393: <br><br><li>
394: Verify dependencies. Peruse your logs to verify the port did detect what is
395: mentioned in DEPENDS, and nothing more. Check names for hidden dependencies
396: (stuff that exists elsewhere in the ports tree and might be detected if the
397: user installs some other ports first).
398: <br><br><li>
399: Verify shared library dependencies. Run <code>make lib-depends-check</code>
400: and add every <code>LIB_DEPENDS</code> or <code>WANTLIB</code> annotation
401: that is needed until it runs cleanly (run <code>make clean=package</code>
402: to remove the old package after updating the port's Makefile).
1.62 espie 403: You may want to read
404: <a href="porting/update.html">the update guidelines</a>
405: to understand why this is so important.
1.61 espie 406: <br><br><li>
407: Check for regression tests, and whether they run cleanly. Set
408: <code>NO_REGRESS=Yes</code> if a port has no test infrastructure.
409: Please note: do not set <code>NO_REGRESS</code> if a port has an empty
410: regression infrastructure.
1.22 rohee 411: <br><br><li>
1.20 turan 412: Mail <a href="mailto:ports@openbsd.org">ports@openbsd.org</a> with a short
1.65 simon 413: note asking for comments and testing. Make sure to attach the port/patch to
414: this email and send it out (mailinglist archives just contain the mails itself).
1.20 turan 415: <p>
416: Try to get others to test it on a variety of platforms for you.
417: <ul><li>
1.60 miod 418: The AMD64 Opteron systems are good because they are fast, and because
419: <code>sizeof(int) != sizeof(long)</code> on this platform.
1.20 turan 420: <li>
1.60 miod 421: Sun SPARC and UltraSPARC are good because they are very common and because
422: their byte order is the opposite of i386; if you developed on SPARC, of course,
423: you'd want it tested on i386.
1.20 turan 424: </ul>
425:
1.22 rohee 426: <br><li>
1.20 turan 427: Incorporate any feedback you get. Test it again on your platform.
428: Get those who gave you feedback to test it again from your new port.
429:
1.22 rohee 430: <br><br><li>
1.20 turan 431: Finally, include it in the "ports" tree.
432: If you do not have CVS access, ask someone on
1.30 espie 433: <a href="mailto:ports@openbsd.org">ports@openbsd.org</a> to commit it.
1.9 espie 434:
1.22 rohee 435: <br><br><li>
1.20 turan 436: If you are a developer with CVS access, check it in.
437: We normally use "import" for a new port,
438: rather than adding a zillion (or a dozen) files individually.
439: Import uses "vendor branch" version numbers like 1.1.1.1, but don't worry
440: about that! :-) If you make changes to a specific file (edit, then
441: cvs commit), it will be 1.2, and that will be used.
442: <p>
443: In short, import is typically used when a port is created.
444: From that point on cvs add and cvs rm are typically used to add or remove
1.53 jose 445: files, and the normal edit->commit cycle for changes.
1.20 turan 446: You might use something like this:
447: <pre>
1.45 jsyn 448: $ cd kaffe1
1.47 david 449: $ make clean # you really don't want to check in all of work!
1.45 jsyn 450: $ cvs -d cvs.openbsd.org:/cvs import -m 'kaffe port' ports/lang/kaffe1 \
1.58 david 451: <i>YourName</i> <i>YourName_YYYY-MMM-DD</i>
1.20 turan 452: </pre>
453: <ul><li>
454: -d cvs.openbsd.org:/cvs says where cvs lives. This can be omitted if you
1.21 form 455: have a CVSROOT environment variable defined.
1.20 turan 456: <li>
457: -m 'kaffe port' is your login message. Change it to whatever you like
458: <li>
459: ports/lang/kaffe1 is the path relative to /cvs where the port lives
460: <li>
1.45 jsyn 461: <i>YourName</i> (replaced with your login name) is the 'vendor tag'.
1.20 turan 462: You imported it so you are the vendor.
463: <li>
464: <i>YourName_YYYY-MMM-DD</i> (e.g., ian_2000-Jan-01)
465: is the 'vendor release tag'. This is as good as any.
466: </ul>
1.45 jsyn 467: <br>
1.20 turan 468: As a real example, here is the output of checking in the Kaffe1 port,
469: which one of us did on September 8, 1998:
470: <pre>
1.4 ian 471: $ cd kaffe1
472: $ make clean >/dev/null
473: $ cvs import -m 'kaffe1.0(==JDK1.1) port' ports/lang/kaffe1 ian ian_1998-Sep-08
474: ian@cvs.openbsd.org's password: (not shown, obviously)
475: I ports/lang/kaffe1/CVS
476: I ports/lang/kaffe1/files/CVS
477: I ports/lang/kaffe1/pkg/CVS
478: N ports/lang/kaffe1/Makefile
479: cvs server: Importing /cvs/ports/lang/kaffe1/files
480: N ports/lang/kaffe1/files/md5
481: cvs server: Importing /cvs/ports/lang/kaffe1/pkg
482: N ports/lang/kaffe1/pkg/COMMENT
483: N ports/lang/kaffe1/pkg/DESCR
484: N ports/lang/kaffe1/pkg/PLIST
485:
486: No conflicts created by this import
487: $
1.20 turan 488: </pre>
489:
1.22 rohee 490: <li>
1.20 turan 491: Last but not least, add a one-line entry for the new port
1.45 jsyn 492: in its parent directory's Makefile, e.g., for ports/lang/kaffe1,
1.20 turan 493: add it to ports/lang/Makefile.
494:
1.22 rohee 495: <br><br><li>
1.20 turan 496: Maintain the port! As time goes by, problems may arise, or new versions
497: of the software may be released. You should strive to keep your port up
1.22 rohee 498: to date. In other words - iterate, test, test, iterate...
1.29 espie 499:
1.45 jsyn 500: <br><br><li>
1.29 espie 501: When updating a port, remember to handle dependencies! You shouldn't break any
502: port that depends on yours. In case of problems, communicate with the
503: maintainers of such ports. Likewise, be alert for dependency updates, and
504: check that the maintainer did their job.
1.22 rohee 505: </ol>
1.20 turan 506:
507: Thank you for supporting the OpenBSD "ports" process!
508: <hr>
1.53 jose 509: <a href="porting.html"><img height=24 width=24 src="back.gif"
510: border=0 alt="Porting"></a>
1.20 turan 511: <a href="mailto:www@openbsd.org">www@openbsd.org</a>
1.66 ! espie 512: <br><small>$OpenBSD: checklist.html,v 1.65 2007/05/15 20:17:18 simon Exp $</small>
1.20 turan 513: </body>
1.1 marc 514: </html>
![[BACK]](/icons/back.gif){kind=icon}
Return to checklist.html CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [local] / www