www/checklist.html - diff

Return to checklist.html CVS log

Up to [local] / www

Diff for /www/Attic/checklist.html between version 1.21 and 1.22

version 1.21, 2000/03/11 07:43:53

version 1.22, 2000/03/11 18:49:19

Line 6

<title>OpenBSD Porting Checklist</title>

</head>

<h2>OpenBSD Porting Checklist</h2>

Line 24

<hr>

<ol>

<li>

<li>

If you want to be a maintainer, subscribe to

<a href="mailto:ports@openbsd.org"> ports@openbsd.org.</a>

Line 36

good advice or test ports for you.

</ul>

<li>

<li>

Check out a copy of the ports tree from cvs.

You can find instructions to do this at

http://www.openbsd.org/anoncvs.html</a>.

<li>

<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>.

Line 52

Create these empty files <code>pkg/COMMENT, pkg/DESCR, pkg/PLIST</code>

</ul>

<li>

<li>

Add the fetch portions of the Makefile.

Fill in EXTRACT_SUFFIX if its anything besides .tar.gz. Other examples are

Line 61

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/ Don't forget

is kept. E.g. ftp://ftp.openbsd.org/pub/OpenBSD/distfiles/ . Don't forget

the trailing slash. Try to have at least three distinct sites as well.

the trailing slash. 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

Line 76

For more complex ports, you have more options and tools available to you:

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

(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

Line 107

mirror-distfiles will fetch those supplementary files that the casual user doesn't need.

</ul>

<li>

<li>

Create a checksum in files/md5 by typing make makesum.

Then verify the checksum is correct by typing make checksum

Line 125

Patches that need specific treatment should be mentioned in DISTFILES, and removed from EXTRACT_ONLY, for historic reasons.

</ul>

<li>

<li>

Extract the port with make extract. Pay attention to where the base

of the sources are. Usually, its work/DISTNAME You may need to modify

the Makefile's WRKDIST variable if it is different.

<li>

<li>

Read the installation documentation and note what you have to do to build

the port and any special options that might be needed.

<li>

<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

Line 152

Line 153

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>.

<li>

<li>

Add configuration options to Makefile and/or create the configuration script.

You can add a port configuration script named `configure' to a directory

Line 169

Line 170

overwrite it.

</ul>

<li>

<li>

Try building the port with make build.

If you're lucky, the port will go all the way through without errors.

Line 183

Line 184

and patch your port.

</ul>

<li>

<li>

Begin and cycle of make build, generate a patch, and

make clean patch.

Line 211

Line 212

Please feed your patches back to the author of that piece of software.

</ul>

<li>

<li>

Try setting <code>SEPARATE_BUILD</code>

If the port can build with object files outside its source tree,

Line 222

Line 223

restart the cycle at <code>configure</code> most of the time.

</ul>

<li>

<li>

Peruse the output (if any) and tweak any options in the Makefile.

To repeat issue the command `make clean configure'.

Note: make sure host dependent files go in /etc or

/etc/<name>, but NEVER REPLACE OR MODIFY existing files

/etc/<name>, but NEVER REPLACE OR MODIFY existing files

in /etc. Best to have install place

in /usr/local/share/<name> and then copy to

/etc or /etc/<name> only if the files do not exist.

Line 253

Line 254

misc documentation: /usr/local/share/doc/<name>

</pre>

<li>

<li>

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

if possible, especially security related warnings.

<li>

<li>

Control SEPARATE_BUILD semantics.

You have to do this only if the port builds with

SEPARATE_BUILD defined.

Line 271

Line 273

distinct arches simultaneously may meet with problems, as some

source files may be regenerated at awkward moments.

<li>

<li>

Edit pkg/DESCR, pkg/COMMENT, pkg/PLIST.

<ul>

<li>

Line 286

Line 288

PLIST is kept empty at this point.

</ul>

<li>

<li>

Install the application with make install

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.

<li>

<li>

Check port for security holes again. This is

especially important for network and setuid programs. See

<a href="porting.html#security">our security recommendations</a>

Line 311

Line 313

The server makes extensive use of strlcpy/strlcat/snprintf.

</pre>

<li>

<li>

Create pkg/PLIST. After the install is complete use the developer's command,

make plist which makes the file PLIST-auto in the pkg directory.

This file is a candidate packing list.

Line 351

Line 353

shared libraries.

</ul>

<li>

<li>

Keep repeating uninstall and reinstall until perfect.

Perfect is when everything installs and uninstalls

in its proper location. `pkg_delete <pkg_name>' is

Line 361

Line 363

<code>find /usr/local -newer work/.install_started -print</code>

should only list standard directory names.

<li>

<li>

Test the packaging:

After the port installs correctly issue the command

<code>make package</code> to create a package. To test the

Line 369

Line 371

<code>pkg_add</code> The results after an add should EXACTLY

match the results after a `make install'.

<li>

<li>

Mail <a href="mailto:ports@openbsd.org">ports@openbsd.org</a> with a short

note asking for comments and testing. Attach the port to this email and

sent it out. If you don't get any comments, send email to

Line 378

Line 380

Try to get others to test it on a variety of platforms for you.

The DEC Alpha is good because it has only static libraries and because

sizeof(int) != sizeof(long)

<code>sizeof(int) != sizeof(long)</code>

<li>

Sun SPARC is good because it is very common and because its byte order is

the reverse of i386; if you developed on SPARC, of course, you'd want it

tested on i386).

</ul>

<li>

<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.

<li>

<li>

Finally, include it in the "ports" tree.

If you do not have CVS access, ask someone on

Line 398

Line 399

about me, <a href="turan@openbsd.org">turan@openbsd.org</a> if no one

picks it up.

<li>

<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.

Line 452

Line 453

</pre>

<li>

<li>

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,

add it to ports/lang/Makefile.

<li>

<li>

Maintain the port! 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. In other words - iterate, test, test, iterate, ...

to date. In other words - iterate, test, test, iterate...

</ul>

</ol>

Thank you for supporting the OpenBSD "ports" process!

<hr>