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