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