Annotation of www/checklist.html, Revision 1.13
1.1 marc 1: <html>
2: <head>
3: <meta http-equiv="Content-Type"
4: content="text/html; charset=iso-8859-1">
5: <meta name="resource-type"
6: content="document">
7: <meta name="description"
1.3 marc 8: CONTENT="How to make an OpenBSD port; porting checklist">
1.1 marc 9: <meta name="keywords"
10: content="openbsd,ports">
11: <meta name="distribution"
12: content="global">
13: <meta name="copyright"
14: content="This document copyright 1998 by the OpenBSD project">
1.3 marc 15: <title>OpenBSD Porting Checklist</title>
1.1 marc 16: <link rev="made" HREF="mailto:www@openbsd.org">
17: </head>
18: <body text="#000000" bgcolor="#FFFFFF" link="#23238E">
19: <img height=30 width=141 src=images/smalltitle.gif alt="[OpenBSD]" >
20:
1.3 marc 21: <h2><font color=#e00000>OpenBSD Porting Checklist</font></h2>
1.1 marc 22:
23: I use this checklist as a reminder of things to do when creating
24: new ports and when validating old ports. I don't claim this list
25: is totally accurate, much less perfect, but only hope that some
1.3 marc 26: find it useful. Direct any questions and/or comments to me at
1.1 marc 27: <a href=mailto:marc@snafu.org>marc@snafu.org</a>.
28: <p>
29: <ol>
1.4 ian 30: <li>To avoid duplication, subscribe to the ports@openbsd.org
31: mailing list - somebody may be already working on the same port as you.
32: <p>
1.11 marc 33: <li>Create Makefile -- start with the provided Makefile template
34: <code>/usr/ports/Makefile.template</code>. This file can
35: be retrieved from any of the anoncvs servers or via the
36: OpenBSD cvs/web source brouser system
37: <a href="http://www.openbsd.org/cgi-bin/cvsweb/">http://www.openbsd.org/cgi-bin/cvsweb/</a>.
1.1 marc 38: <p>
39: <li><code>make fetch</code><br>
40: This verifies that the master site, distname, and extract suffix are
41: correct.
42: <p>
43: <li><code>make makesum</code><br>
44: This creates the files directory and the md5 checksum for the
45: fetched files.
46: <p>
47: <li><code>make extract</code><br>
48: Ensures that the file can be extracted into the work directory.
49: This also verifies that the checksum created in step 3 is good.
50: <p>
51: <li>Create initial patches<br>
52: When the extract is complete cd to the work directory and read
53: any install docs. You may need to modify the WRKSRC variable
54: in the makefile as well as generate initial patches to configure
55: for openbsd.
56: <p>Note: Patches go in the directory `patches' and are names patch-xx
57: where xx should be aa, ab, ..., az, ba, bb ... zz.
58: <ul>
59: <li>only patch one source file per patchfile, please
60: <li>use diff -u to generate patches
61: <li>all patches MUST be relative to ${WRKSRC}
62: </ul>
63: <p>
64: <li><code>make patch</code><br>
65: this will apply patches to the extracted sources. If you want
66: to see the output use the command:
67: <p><code>make PATCH_DEBUG=YES patch</code>
1.7 espie 68: <p>The easiest way to re-run patches is to `make clean && make patch'.
1.1 marc 69: This will delete the work directory and re-extract and patch.
70: <p>
71: <li>add configuration options to Makefile and/or create configuration
72: script.<br>
73: You can add a port configuration script named `configure' to a
74: directory named scripts. This will be run before any
75: configuration specified by GNU_CONFIGURE or HAS_CONFIGURE is run.
76: <p>If GNU_CONFIGURE is used you may want to run ./configure --help
77: to see what options are available. Anything thay you may want to
78: override can be changed by adding the --option flags to the
79: CONFIGURE_ARGS parameter in the Makefile
80: <p>
1.12 espie 81: <li>try setting <code>SEPARATE_BUILD</code><br>
82: If the port can build with object files outside its source tree,
83: this is cleaner (many programs using <code>GNU_CONFIGURE</code> can),
84: and may help people who mount their ports tree on several arches.
85: This can also spare you some effort, as you will possibly be able to
86: restart the cycle at <code>configure</code> most of the time.
87: <p>
1.1 marc 88: <li><code>make configure</code><br>
89: Peruse the output (if any) and tweak any options in the Makefile.
1.7 espie 90: To repeat issue the command `make clean && make configure'.
1.1 marc 91: <p>Note: make sure host dependent files go in /etc or /etc/<name>, but
92: NEVER replace existing files in /etc. Best to have install place
93: in /usr/local/lib/<name> and then copy to /etc or /etc/<name> only
94: the files do not exist.
95: <p>The OpenBSD file locations are:
1.9 espie 96:
1.1 marc 97: <pre>
98: user executables: /usr/local/bin
99: system admin executables: /usr/local/sbin
100: program executables: /usr/local/libexec
101: libraries /usr/local/lib
102: architecture dependent data /usr/local/lib/<name>
103: installed include files: /usr/local/include or
104: /usr/local/include/<name>
105: single-machine data: /etc or /etc/<name>
106: local state: /var/run
107: GNU info files: /usr/local/info
108: man pages: /usr/local/man/...
109: read-only architecture-independent: /usr/local/share/<name>
110: misc documentation: /usr/local/share/doc/<name>
111: </pre>
1.9 espie 112:
1.1 marc 113: <p>
114: <li><code>make</code><br>
115: Begin a cycle of makes until the port is ready. Patch (see above)
116: clean, and make until the port is generated. Get rid of all warnings
117: if possible, especially security related warnings.
118: <p>
1.12 espie 119: <li>Control <code>SEPARATE_BUILD</code> semantics<br>
120: You have to do this only if the port builds with
121: <code>SEPARATE_BUILD</code> defined.
122: Ideally, the port should no longer modify any file in
123: <code>${WRKSRC}</code> after <code>make patch</code>.
124: You can check this by making sure you don't have any write access
125: to <code>${WRKSRC}</code>. Then you can set
126: <code>SEPARATE_BUILD=concurrent</code>: someone can use the same
127: source tree to build on distinct arches simultaneously.
128: Otherwise, set <code>SEPARATE_BUILD=simple</code>: building on
129: distinct arches simultaneously may meet with problems, as some
130: source files may be regenerated at awkward moments.
131: <p>
1.1 marc 132: <li><code>mkdir pkg; touch pkg/{DESCR,COMMENT,PLIST}</code><br>
133: Create dummy versions of the package files. Edit DESCR and COMMENT.
1.7 espie 134: <p>COMMENT is a <strong>SHORT</strong> one-line description of the port
135: (max. 60 characters). Do NOT include the
1.1 marc 136: package name (or version number of the software) in the comment.
137: <p>DESCR is a longer description of the port. One to a few paragraphs
138: concisely explaining what the port does is sufficient.
139: <p>PLIST is kept empty at this point.
140: <p>
141: <li><code>sudo make install</code><br>
142: install the application.
143: <p>
1.9 espie 144: <li><strong>Check port for security holes again</strong>. This is
145: especially important for network and setuid programs. See
146: <a href="porting.html#security">our security recommendations</a>
147: for that. Log interesting stuff and fixes in the
148: <code>pkg/SECURITY</code> file. This file
149: should list audited potential problems, along with relevant patches,
150: so that another person can see at first glance what has been done.
151: Example:
152: <pre>
153:
154: $OpenBDS$
155:
156: ${WRKDIR}/receiver.c
157: call to mktemp (wrapper function do_mktemp) does seem to be correct.
158:
159: The server makes extensive use of strlcpy/strlcat/snprintf.
160:
161: </pre>
162:
1.1 marc 163: <li>Create pkg/PLIST<br>
164: After the install is complete use the developers command:
165: <p><code>make plist</code>
166: <p>which makes a the file PLIST-auto in the pkg directory. This file
167: is a candidate packing list. Beware: the files are found by
168: timestamp. This means it does NOT:
169: <ul>
170: <li>list any files installed with `tar' as their timestamp
171: will not change and thus won't be found by `find'
172: <li>update the <code>info/dir</code> file if .info files are
173: added. You'll have to add that by hand. Also, be sure that
174: the <code>info/dir</code> is not part of the PLIST.
175: <li>try to do anything special with links or symbolic links. A
176: cursory test of tar shows it does the right thing with links
177: and symbolic links so I don't see why we need to special case
178: anything in the packing list. But still...
179: </ul>
180: <p>Peruse `PLIST-auto' and verify that everything was installed and
181: that it was installed in the proper locations. Anything not installed
182: can be added to a port Makefile `post-install' rule.
183: <p>Copy `PLIST-auto' to `PLIST'
1.10 marc 184: <p>Ports that install shared libraries will need two versions of
185: the PLIST file. <code>PLIST</code> describes the files installed on
186: those architectures that support shared libraries, and
1.13 ! wvdputte 187: <code>PLIST.noshared</code> describes the files installed on
1.10 marc 188: architectures that do not support shared libs. Typically,
189: <code>PLIST.noshared</code> is a copy of <code>PLIST</code>
190: less references to any shared libraries.
1.1 marc 191: <p>
192: <li>uninstall and reinstall; repeat until perfect.<br>
193: <em>Perfect</em> is when everything installs and uninstalls
194: in its proper location. `pkg_delete <pkg_name>' is used to
195: uninstall. `sudo make reinstall' is used to reinstall. See the
196: `pkg_create' man page for other commands that may be added to PLIST
197: to ensure all is cleaned up. After an uninstall the command
198: <p><code>find /usr/local -newer work/.install_started -print</code>
199: <p>should only list standard directory names.
200: <p>
201: <li>Create package:<br>
202: After the port installs correctly issue the command
203: <code>make package</code> to create a package. To test the
204: package first do a <code>pkg_delete</code> and then do a
205: <code>pkg_add</code> The results after an add should EXACTLY
206: match the results after a `make install'.
1.4 ian 207: <p>
208: <LI>Distribute it!</BR>
209: Since the whole point of this process
210: is to make your ported version of the software available to
211: other OpenBSD users, you now need to disseminate it.
212: <UL>
213: <LI>First, get others to test it on a variety of
214: platforms (the DEC Alpha is good because it has only static libraries
215: and because sizeof int != sizeof long; Sun SPARC is good because it is
216: very common and because its byte order is the reverse of i386; if you
217: developed on SPARC, of course, you'd want it tested on i386).
218: <P>The ports@openbsd mailing list is a good place to find porting-savy
219: people with different platforms!
220: <LI>Incorporate any feedback you get. Test it again on your platform.
221: Get those who gave you feedback to test it again from your new port.
222: <LI>Finally, include it in the "ports" tree.
223: If you are a developer with CVS access, check it in.
224: We normally use "import" for a new port,
225: rather than adding a zillion (or a dozen) files individually.
226: Import uses "vendor branch" version numbers like 1.1.1.1, but don't worry
227: about that! :-) If you make changes to a specific file (edit, then
228: cvs commit), it will be 1.2, and that will be used.
229: <P>
230: In short, import is typically used when a port is created.
231: From that point on cvs add and cvs rm are typically used to add or remove
232: files, and the normal edit->commit cycle for changes.
233: <P>
234: You might use something like this:
235: <PRE>
236: cd kaffe1
237: make clean # you really really don't want to check in all of work!
238: cvs -d cvs.openbsd.org:/cvs import -m 'kaffe port' ports/lang/kaffe1 \
239: <I>YourName</I> <I>YourName_YYYY-MMM-DD</I>
240: </PRE>
241: <P>-d cvs.openbsd.org:/cvs says where cvs lives. This can be omitted if you
242: have a CVS_ROOT environment variable defined.
243: <P>-m 'kaffe port' is your login message. Change it to whatever you like
244: <P>ports/lang/kaffe1 is the path relative to /cvs where the port lives
245: <P><I>YourName</I> (replaced with your login name) is the "vendor tag".
246: You imported it so you are the vendor.
247: <P><I>YourName_YYYY-MMM-DD</I> (e.g., ian_2000-Jan-01)
248: is the 'vendor release tag'. This is as good as any.
249: <P>As a real example, here is the output of checking in the Kaffe1 port,
250: which one of us did on September 8, 1998:
251: <PRE>
252: $ cd kaffe1
253: $ make clean >/dev/null
254: $ cvs import -m 'kaffe1.0(==JDK1.1) port' ports/lang/kaffe1 ian ian_1998-Sep-08
255: ian@cvs.openbsd.org's password: (not shown, obviously)
256: I ports/lang/kaffe1/CVS
257: I ports/lang/kaffe1/files/CVS
258: I ports/lang/kaffe1/pkg/CVS
259: N ports/lang/kaffe1/Makefile
260: cvs server: Importing /cvs/ports/lang/kaffe1/files
261: N ports/lang/kaffe1/files/md5
262: cvs server: Importing /cvs/ports/lang/kaffe1/pkg
263: N ports/lang/kaffe1/pkg/COMMENT
264: N ports/lang/kaffe1/pkg/DESCR
265: N ports/lang/kaffe1/pkg/PLIST
266:
267: No conflicts created by this import
268: $
269: </PRE>
1.5 ian 270: <P>Last but not least, add a one-line entry for the new port
271: in its parent directory's makefile, i.e., for ports/lang/kaffe1,
272: add it to ports/lang/Makefile.
1.4 ian 273: <P>If you do not have CVS commit access, send mail to the ports
274: maintainers at ports@openbsd.org,
275: stating that you have a port ready to go into the tree. List the
276: name and version of the program, the platforms it's been tested on,
277: and any limitations.
278: </UL>
279: <P>
280: <LI>Maintain the port!<BR>
281: As time goes by, problems may arise, or new versions of the software
282: may be released. You should strive to keep your port up to date.
283: In other words - iterate, test, test, iterate, ...
1.1 marc 284: </ol>
1.4 ian 285: Thank you for supporting the OpenBSD "ports" process!
1.1 marc 286: <hr>
287: <a href="porting.html"><img height=24 width=24 src=back.gif
288: border=0 alt=Porting></a>
289: <a href=mailto:www@openbsd.org>www@openbsd.org</a>
1.13 ! wvdputte 290: <br><small>$OpenBSD: checklist.html,v 1.12 1999/03/08 00:34:39 espie Exp $</small>
1.1 marc 291: </body>
292: </html>